这是我参与8月更文挑战的第27天，活动详情查看：8月更文挑战

一面向对象基础

1.1 基本概念

1.1.1 对象

由数据及其操作所构成的封装体，是系统中用来描述客观事务的一个实体，是构成系统的一个基本单位。一个对象通常可以由对象名、属性和方法3个部分组成。

1.1.1 类的分类

现实世界中实体的形式化描述，类将该实体的属性（数据）和操作（函数）封装在一起。对象是类的实例，类是对象的模板。

实体类`
边界类
控制类实体类的对象表示现实世界中真实的实体，如人、物等。接口类(边界类）的对象为用户提供一种与系统合作交互的方式，分为人和系统两大类，其中人的接口可以是显示屏、窗口、Web 窗体、对话框、菜单、列表框、其他显示控制、条形码、二维码或者用户与系统交互的其他方法。系统接口涉及到把数据发送到其他系统，或者从其他系统接收数据。控制类的对象用来控制活动流，充当协调者。

1.1.2 抽象

通过特定的实例抽取共同特征以后形成概念的过程。它强调主要特征，忽略次要特征。一个对象是现实世界中一个实体的抽象，一个类是一组对象的抽象，抽象是一种单一化的描述，它强调给出与应用相关的特性，抛弃不相关的特性。

1.1.3 封装

是一种信息隐蔽技术，将相关的概念组成一个单元模块，并通过一个名称来引用。面向对象封装是将数据和基于数据的操作封装成一个整体对象,对数据的访问或修改只能通过对象对外提供的接口进行。

1.1.4 继承

表示类之间的层次关系(父类与子类)，这种关系使得某类对象可以继承另外一类对象的特征，又可分为单继承和多继承。

1.1.5 多态

不同的对象收到同一个消息时产生完全不同的结果。包括参数多态（不同类型参数多种结构类型)、包含多态（父子类型关系)、过载多态（类似于重载，一个名字不同含义)、强制多态（强制类型转换）四种类型。多态由继承机制支持，将通用消息放在抽象层，具体不同的功能实现放在低层。

1.1.6 接口

描述对操作规范的说明，其只说明操作应该做什么，并没有定义操作如何做。

1.1.7 消息

体现对象间的交互，通过它向目标对象发送操作请求。

1.1.8 覆盖

子类在原有父类接口的基础上，用适合于自己要求的实现去置换父类中的相应实现。即在子类中重定义一个与父类同名同参的方法。

1.1.9 函数重载

与覆盖要区分开，函数重载与子类父类无关，且函数是同名不同参数。

1.1.10 绑定

是一个把过程调用和响应调用所需要执行的代码加以结合的过程。在一般的程序设计语言中，绑定是在编译时进行的，叫作静态绑定。动态绑定则是在运行时进行的，因此，一个给定的过程调用和代码的结合直到调用发生时才进行。

1.2 面向对象的分析

是为了确定问题域，理解问题。包含五个活动:认定对象、组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信息。

1.3 面向对象需求建模

1.4 面向对象的设计

是设计分析模型和实现相应源代码，设计问题域的解决方案，与技术相关。oOD同样应遵循抽象、信息隐蔽、功能独立、模块化等设计准则。

面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成;设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。

1.5 面向对象的设计原则:

单一责任原则。就一个类而言，应该仅有一个引起它变化的原因。即，当需要修改某个类的时候原因有且只有一个，让一个类只做一种类型责任。
开放一封闭原则。软件实体（类、模块、函数等）应该是可以扩展的，即开放的;但是不可修改的，即封闭的。
里氏替换原则。子类型必须能够替换掉他们的基类型。即，在任何父类可以出现的地方，都可以用子类的实例来赋值给父类型的引用。
依赖倒置原则。抽象不应该依赖于细节，细节应该依赖于抽象。即，高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
接口分离原则。不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。即:依赖于抽象，不要依赖于具体，同时在抽象级别不应该有对于细节的依赖。这样做的好处就在于可以最大限度地应对可能的变化。上述(1)～(5)是面向对象方法中的五大原则。除了这五大原则之外，Robert C.Martin提出的面向对象设计原则还包括以下几个。
重用发布等价原则。重用的粒度就是发布的粒度。
共同封闭原则。包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
共同重用原则。一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
无环依赖原则。在包的依赖关系图中不允许存在环，即包之间的结构必须是一个直接的五环图形。
稳定依赖原则。朝着稳定的方向进行依赖。
稳定抽象原则。包的抽象程度应该和其稳定程度一致。

1.6 面向对象的测试

一般来说，对面向对象软件的测试可分为下列4个层次进行。

算法层。测试类中定义的每个方法，基本上相当于传统软件测试中的单元测试。
类层。测试封装在同一个类中的所有方法与属性之间的相互作用。在向面对象软件中类是基本模块，因此可以认为这是面向对象测试中所特有的模块测试。
模板层。测试一组协同工作的类之间的相互作用，大体上相当于传统软件测试中的集成测试，但是也有面向对象软件的特点（例如，对象之间通过发送消息相互作用)。
系统层。把各个子系统组装成完整的面向对象软件系统，在组装过程中同时进行测试。

二 UML

UML(统一建模语言):是一种可视化的建模语言，而非程序设计语言，支持从需求分析开始的软件开发的全过程。从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。

构造块。UML有三种基本的构造块,分别是事物( thing)、关系(relationship)和图( diagram)。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。
公共机制。公共机制是指达到特定目标的公共UML方法。
规则。规则是构造块如何放在一起的规定。

2.1 事物

结构事物:模型的静态部分，如类、接口、用例、构件等;行为事物:模型的动态部分，如交互、活动、状态机;
分组事物:模型的组织部分，如包;
注释事物:模型的解释部分，依附于一个元素或一组元素之上对其进行约束或解释的简单符号。
部分事物UML图形如下所示:

2.2关系

依赖: 一个事物的语义依赖于另一个事物的语义的变化而变化
关联:是一种结构关系，描述了一-组链，链是对象之间的连接。分为组合和聚合，都是部分和整体的关系，其中组合事物之间关系更强。两个类之间的关联，实际上是两个类所扮演角色的关联，因此，两个类之间可以有多个由不同角色标识的关联。
泛化:一般/特殊的关系，子类和父类之间的关系.
实现:一个类元指定了另一个类元保证执行的契约。关系UML图形代号如下:

2.3 图

用例图：从用户角度描述系统功能。
类图：描述系统中类的静态结构。
对象图：系统中的多个对象在某一时刻的状态。
状态图：是描述状态到状态控制流，常用于动态特性建模
活动图：描述了业务实现用例的工作流程
顺序图：对象之间的动态合作关系，强调对象发送消息的顺序，同时显示对象之间的交互
协作图：描述对象之间的协助关系
构件图：一种特殊的UML图来描述系统的静态实现视图
部署图：定义系统中软硬件的物理体系结构
包图：对构成系统的模型元素进行分组整理的图
组合结构图：表示类或者构建内部结构的图
交互概览图：用活动图来表示多个交互之间的控制关系的图

2.4 UML 4+1视图

逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
部署视图。部署视图把构件部署到- -组物理节点上，表示软件到硬件的映射和分布结构。
用例视图。用例视图是最基本的需求分析模型。

三设计模式

3.1 层次结构

架构模式:软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策。
设计模式:每一个设计模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能-次又一次地使用该方案而不必做重复劳动。设计模式的核心在于提供了相关问题的解决方案，使得人们可以更加简单方便的复用成功的的设计和体系结构。四个基本要素:模式名称、问题(应该在何时使用模式)、解决方案(设计的内容)、效果(模式应用的效果)。
惯用法:是最低层的模式，关注软件系统的设计与实现,实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。例如引用一计数就是C++语言中的一种惯用法。.

3.2 具体设计模式分类

分为三类，创建型模式主要是处理创建对象，结构型模式主要是处理类和对象的组合，行为型模式主要是描述类或者对象的交互行为，总览图如下:

十二 面向对象技术

一 面向对象基础