面向对象的设计

6.6　面向对象的设计

6.6.1　面向对象的概念

（1）实体类：对现实中的实体的描述。不同的实体类包含不同的实体属性，同时还含有属性的行为。

（2）接口类：主要是帮助用户在不同的系统之间进行信息通信的组件。

（3）控制类：包含有系统的业务规则来对系统接收和发送的信息进行约束。

6.6.2　面向对象设计过程

系统分析人员在对象分析中，基于理想条件和依赖一些硬件和软件方案确定对象和用例。在面向对象设计时，就需要对这些对象进行精练，使之能反映所建议的方案的实际的环境。面向对象设计的过程如下：对模型进行精练处理；建模支持用例情境的对象交互、行为和状态；修改对象模型使之反映实现环境。

1．对模型进行精炼处理

用例建模不是一蹴而就的，它是一个反复迭代的过程，从而也给我们提供了一个对用例进行精练的过程。在这个步骤中我们要对每个用例进行处理，使它们能反映现实环境。重要的是除了每个用例都要被高度精练细化外，还要描述用户同系统的交互。用户可以使用这些用例验证系统设计。

2．建模支持用例情境的对象交互、行为和状态

在上一步在我们精练了用例，在这一步要我们进行的是确定和分类设计类。关于面向对象的类的分类在小节开始已讲述，这些设计类除了要求要说明用例中的功能需求外，还要确定类之间的交互行为和状态。同时还要确定类的属性，

3．修改对象模型使之反映实现环境

设计了对象及其所需的交互现在就可以对类图加以精化了，以表示程序中的软件类。设计类图主要包括如下内容：类、关联关系泛化关系、聚合关系、属性和属性类型、方法、依赖关系。

通过如下几步可以将OOA中的类图转换成设计类图：向图中添加设计对象、向设计对象中添加属性和属性的类型、添加属性的修饰符、向设计对象添加方法、为添加的方法添加修饰符、添加类与类之间的关系。

6.6.3　设计模式

设计模式是一个普遍的可重复使用的解决方案，软件设计一个经常出现的问题。设计模式不是一个完整的设计，可以直接转换成代码。这是一个描述或模板如何解决，可以在许多不同的情况下使用的问题。面向对象的设计模式之间的关系和通常显示类或对象的作用，但没有具体的最终应用类或所涉及的对象。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。关于设计模式的详细内容限于篇幅只做简要介绍。

1．单一职责原则

作为一个例子，考虑一个模块，编译，并打印了一份报告。这种模块是可以改变的原因有两个。首先，报告的内容可以改变。其次，报告的格式可以更改。

如果一个类承担的职责过多，就等于将这些职责耦合在一起，一个职责发生变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏。

2．开放封闭原则

软件设计本身所追求的目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。其他的设计原则，很多时候是为实现这一目标服务的，例如以Liskov替换原则实现最佳的、正确的继承层次，就能保证不会违反开放封闭原则。关于开放封闭原则，其核心的思想是：软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。

对于违反这一原则的类，必须进行重构来改善，常用于实现的设计模式主要有Template Method模式和Strategy模式。而封装变化，是实现这一原则的重要手段，将经常发生变化的状态封装为一个类。

3．Liskov替换原则

里氏替换原则中，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。

里氏代换原则实质上是对“开—闭”原则的补充。实现“开—闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。一般而言，一旦违反了里氏代换原则的，也违背“开—闭”原则，反过来就不一定成立。

4．依赖倒置原则

抽象不应该依赖与细节，细节应当依赖与抽象。要针对接口编程，而不是针对实现编程。传递参数，或者在组合聚合关系中，尽量引用层次高的类。主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画蛇添足的感觉。

5．接口隔离原则

每一个接口应该是一种角色。

6．迪米特法则

如果两个类不必彼此直接通信，那么这两个类就应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三方转发这个调用。