• 面向对象开发

1. 相关概念

1. 对象：由数据及其操作所构成的封装体，是系统中用来描述客观事务的一个实体，是构成系统的一个基本单位。一个对象通常可以由对象名、属性和方法3个部分组成。
2. 类：现实世界中实体的形式化描述，类将该实体的属性（数据）和操作（函数）封装在一起。对象是类的实例，类是对象的模板。

类可以分为三种：实体类、接口类（边界类）和控制类。

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

1. 抽象：通过特定的实例抽取共同特性以后形成概念的过程。它强调主要特征，忽略次要特征。一个对象是现实世界中一个实体的抽象，一个类是一组对象的抽象，抽象是一种单一化的描述，它强调给出与应用相关的特性，抛弃不相关的特性。
2. 封装：是一种信息隐蔽技术，将相关的概念组成一个单元模块，并通过一个名称来引用。面向对象封装是将数据和基于数据的操作封装成一个整体对象，对数据的访问或修改只能通过对象对外提供的接口进行。
3. 继承：表示类之间的层次关系（父类与子类），这种关系使得某类对象可以继承另外一类对象的特征，又可分为单继承和多继承。
4. 多态：不同的对象收到同一个消息时产生完全不同的结果。包括参数多态（不同类型参数多种结构类型）、包含多态（父子类型关系）、过载多态（类似于重载，一个名字不同含义）、强制多态（强制类型转换）四种类型。多态由继承机制支持，将通用消息放在抽象层，具体不同的功能实现放在低层。
5. 接口：描述对操作规范的说明，其只说明操作应该做什么，并没有定义操作如何做。
6. 消息：体现对象间的交互，通过它向目标对象发送操作请求。
7. 覆盖：子类在原有父类接口的基础上，用适合于自己要求的实现去置换父类中的相关实现。即在子类中重定义一个与父类同名同参的方法。
8. 函数重载：与覆盖要区分开，函数重载与子类父类无关，且函数是同名不同参数。
9. 绑定：是一个把过程调用和影响调用所需要执行的代码加以结合的过程。在一般的程序设计语言中，绑定是在编译时进行的，叫作静态绑定。动态绑定则是在运行时进行的，因此，一个给定的过程调用和代码的结合直到调用发生时才进行。

1. 面向对象的分析

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

1. 面向对象需求建模

1. 面向对象的设计

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

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

1. 面向对象的设计原则：

1. 单一责任原则。就一个类而言，应该仅有一个引起它变化的原因。即当需要修改某个类的时候原因有且只有一个，让一个类只做一种类型责任。
2. 开放-封闭原则。软件实体（类、模块、函数等）应该是可以扩展的，即开放的；但是不可修改的，即封闭的。
3. 里氏替换原则。子类型必须能够替换它们的基类型。即在任何父类可以出现的地方，都可以用子类的实例来赋值给父类型的引用。
4. 依赖倒置原则。抽象不应该依赖于细节，细节应该依赖于抽象。即高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
5. 接口分离原则：不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。即：依赖于抽象，不要依赖于具体，同时在抽象级别不应该有对于细节的依赖。这样做的好处就在于可以最大限度地应对可能的变化。

1. 面向对象的测试

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

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

• 统一建模语言UML

1. UML（统一建模语言）：是一种可视化的建模语言，而非程序设计语言，支持从需求分析开始的软件开发的全过程。
2. 从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。
   1. 构造块。UML有三种基本的构造块，分别是事物（thing）、关系（relationship)和图（diagram）。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。
   2. 公共机制。公共机制是指达到特定目标的公共UML方法。
   3. 规则。规则是构造块如何放在一起的规定。
3. 事物

1. 1. 结构事物：模型的静态部分，如类、接口、用例、构件等。
   2. 行为事物：模型的动态部分，如交互、活动、状态机；
   3. 分组事物：模型的组织部分，如包；
   4. 注释事物：模型的解释部分，依附于一个元素或一组元素之上对其进行约束或解释的简单符号。
2. 模型之间的关系
   1. 依赖：一个事物的语义依赖于另一个事物的语义的变化而变化
   2. 关联：是一种结构关系，描述了一组链，链是对象之间的连接。分为组合和聚合，都是部分和整体的关系，其中组合事物之间关系更强。两个类之间的关联，实际上是两个类所扮演的角色的关联，因此，两个类之间可以有多个由不同角色标识的关联。
   3. 泛化：一般/特殊的关系，子类和父类之间的关系。
   4. 实现：一个类元指定了另一个类元保证执行的契约。

1. UML2.0图

1. 类图：静态图，为系统的静态设计图，展示一组对象、接口、协作和它们之间的关系。UML类图如下：

1. 对象图：静态图，展现某一时刻一组对象及它们之间的关系，为类图的某一快照。在没有类图的前提下，对象图就是静态设计视图。如下：

1. 用例图：静态图，展现了一组用例、参与者以及他们之间的关系。用例图中的参与者是人、硬件或其他系统可以扮演的角色；用例是参与者完成的一系列操作，用例之间的关系有扩展、包含、泛化。如下：

1. 序列图：即顺序图、动态图，是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动。有同步消息（进行阻塞调用，调用者中止执行，等待控制权返回，需要等待返回消息，用实心三角箭头表示），异步消息（发出消息后继续执行，不引起调用者阻塞，也不等待返回消息，用空心箭头表示），返回消息（由从右到左的虚线箭头表示）三种。如下：

1. 通信图：动态图，即协作图，强调参加交互的对象的组织。如下：

1. 状态图：动态图，展现了一个状态机，描述单个对象在多个用例中的行为，包括简单状态和组合状态。转换可以通过事件触发器触发，事件触发后相应的监护条件会进行检查。状态图中转换和状态是两个独立的概念，如下：图中方框代表状态，箭头上的代表触发条件，实心圆点为起点和终点。

1. 活动图：动态图，是一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程。活动的分岔和汇合线是一条水平粗线。牢记下图中并发分岔、并发汇合、监护表达式、分支、流等名词及含义。每个分岔的分支数代表了可同时运行的线程数。活动图中能够并行执行的是在一个分岔粗线下的分支上的活动

1. 构件图（组件图）：静态图，为系统静态实现视图，展现了一组构件之间的组织和依赖。如下图：

1. 部署图：静态图，为系统静态部署视图，部署图物理模块的节点分布。它与构件图相关，通常一个结点包含一个或多个构件。其依赖关系类似于包依赖，因此部署组件之间的依赖是单向的类似于包含关系。如下图：

1. UML 4+1视图

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

• 设计模式

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

1. 1. 创新型模式

创新型设计模式	定义	记忆关键字
抽象工厂模式	提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类	抽象接口
构造器模式	将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得出不同的表示	类和构造分离
工厂方法模式	定义一个创建对象的接口，但由于子类决定需要实例化哪一类。使得子类实例化过程推迟	子类决定实例化
原型模式	用原型实例指定创建对象的类型，并且通过拷贝这个原型来创建新的对象	原型实例，拷贝
单例模式	保证一个类只有一个实例，并提供一个访问它的全局访问点	唯一实例

1. 1. 结构型模式

结构型设计模式	定义	记忆关键字
适配器模式	将一个类的接口转换成用户希望得到的另一种接口。它使原来不相容的接口得以协同工作	转换，兼容接口
桥接模式	将类的抽象部分和它的实现部分分离开来，使它们可以独立的变化	抽象和实现分离
组合模式	将对象组合成树形结构以表示“整体-部分”的层次结构，使得用户对单个对象和组合对象的使用具有一致性	整体-部分，树形结构
装饰模式	动态的给一个对象添加一些额外的职责。它提供了用子类扩展功能的一个灵活的替代，比派生一个子类更加灵活	附加职责
外观模式	定义一个高层接口，为子系统中的一组接口提供一个一致的外观，从而简化了该子系统的使用	对外统一接口
享元模式	提供支持大量细粒度对象共享的有效方法	细粒度，共享
代理模式	为其他对象提供一种代理及控制这个对象的访问	代理控制

1. 1. 行为型模式

行为型设计模式	定义	记忆关键字
职责链模式	通过给多个对象处理请求的机会，减少请求的发送者与接收者之间的耦合。将接收对象链接起来，在链中传递请求，直到有一个对象处理这个请求	传递请求、职责链接
命令模式	将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化，将请求排队或记录请求日志，支持可撤销的操作	日志记录、可撤销
解释器模式	给定一种语言，定义它的文法表示，并定义一个解释器，该解释器用来根据文法表示来解释语言中的句子	解释器，虚拟机
迭代模式	提供一种方法来顺序访问一个聚合对象中的各个元素而不需要暴露该对象的内部表示	顺序访问，不暴露内部
中介者模式	用一个中介对象来封装一系列的对象交互。它使各对象不需要显式地相互调用，从而达到低耦合，还可以独立的改变对象间的交互	不直接引用
备忘录模式	在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，从而可以在以后将该对象恢复到原先保存的状态	保存恢复
观察者模式	定义对象间的一种的一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新	通知、自动更新
状态模式	允许一个对象在其内部状态改变时改变它的行为	状态变成类
策略模式	定义一系列算法，把它们一个个封装起来，并且使它们之间可互相替换，从而让算法可以独立于使用它的用户而变化	算法替换
模板方法模式	定义一个操作中的算法骨架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重新定义算法的某些定义步骤
访问者模式	表示一个作用于某对象结构中的各元素的操作，使得在不改变各元素的类的前提下定义作用于这些元素的新操作	数据和操作分离