架构师知识梳理（九）：面向对象

面向对象开发

面向对象分析

面向对象分析的目的是：确定问题域，理解问题。

包含五个活动：

1. 认定对象
2. 组织对象
3. 描述对象间的相互作用
4. 确定对象操作
5. 定义对象内部信息

面向对象需求建模：

 

面向对象设计

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

面向对象的分析模型主要由

• 顶层架构图、
• 用例与用例图、
• 领域概念模型构成

设计模型则包含

• 以包图表示的软件体系结构图
• 以交互图表示的用例实现图
• 完整精确的类图
• 针对复杂对象的状态图
• 用以描述流程化处理过程的活动图等

面对对象的设计原则

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

细节可查看我另一篇文章

面向对象测试

面向对象的软件测试一般可以分为以下几个层次

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

统一建模语言UML

统一建模语言（UML）是一种可视化的建模语言，而非程序设计语言，支持从需求分析开始的软件开发的全过程。

从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。

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

事务

结构事物：模型的静态部分，如类、接口、用例、构件等；

行为事物：模型的动态部分，如交互、活动、状态机；

分组事物：模型的组织部分，如包；

注释事物：模型的解释部分，依附于一个元素或一组元素之上对其进行约束或解释的简单符号。

 

关系

依赖：一个事物的语义依赖于另一个事物的语义的变化而变化。

关联：是一种结构关系，描述了一组链，链是对象之间的连接。分为组合和聚合，都是部分和整体的关系，其中组合事物之间关系更强。两个类之间的关联，实际上是两个类所扮演角色的关联，因此，两个类之间可以有多个由不同角色标识的关联。

泛化：一般/特殊的关系，子类和父类之间的关系。

实现：一个类元指定了另一个类元保证执行的契约。

图

UML类型	目的	版本
类图	描述了系统中对象的类型以及它们之间存在的各种静态关系。	UML 1.x
组件图	描绘了系统中组件提供的、需要的接口、端口等，以及它们之间的关系。	UML 1.x, UML 2.0
对象图	对象图是类图的一个实例，是系统在某个时间点的详细状态的快照。	UML 1.x
轮廓图	轮廓图提供了一种通用的扩展机制，用于为特定域和平台定制UML模型。	UML 2.0
组合结构图	描述了一个“组合结构”的内部结构，以及他们之间的关系。	UML 2.0
部署图	描述了系统内部的软件如何分布在不同的节点上。	UML 1.x
包图	描绘了系统在包层面上的结构设计。	UML 2.0
用例图	指由参与者、用例，边界以及它们之间的关系构成的用于描述系统功能的视图。	UML 1.x
活动图	描述了具体业务用例的实现流程。	UML 1.x
状态机图	描述了对象在它的整个生命周期里，响应不同事件时，执行相关事件的顺序。	UML 1.x
序列图	描述了在用例的特定场景中，对象如何与其他对象交互。	UML 1.x
时序图	时序图被用来显示随时间变化，一个或多个元素的值或状态的更改。	UML 2.0
交互概览图	交互概览图与活动图类似，但是它的节点是交互图。	UML 2.0
通讯图	描述了收发消息的对象的组织关系，强调对象之间的合作关系而不是时间顺序。	UML 1.x叫协作图，UML 2.0改名了

详细样图可见：14种UML图

设计模式

架构模式：软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策。

设计模式：每一个设计模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。设计模式的核心在于提供了相关问题的解决方案，使得人们可以更加简单方便的复用成功的的设计和体系结构。四个基本要素：模式名称、问题（应该在何时使用模式）、解决方案（设计的内容）、效果（模式应用的效果）。

创建型设计模式 

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

结构型设计模式

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

行为型设计模式

 

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