计算机oo设计原则

图2 打印输出的设计2
二、 Liskov替换原则 替换原则
Liskov替换原则最早是由 Liskov于 1987 年在 替换原则最早是由 于 OOPSLA 会议上提出来的［ Lis88］，这个原则指的是子 会议上提出来的［ ］，这个原则指的是子 ］， 类可以替换父类出现在父类能出现的任何地方。 类可以替换父类出现在父类能出现的任何地方。如图 3所 所 示是Liskov替换原则的图示说明。 替换原则的图示说明。 示是 替换原则的图示说明
尽量减少消息模式的数目。只要可能， 尽量减少消息模式的数目。只要可能，就使消息具有 一致的模式，以利于理解。例如，不要在一个消息中， 一致的模式，以利于理解。例如，不要在一个消息中， 地址， 其第一个参数表示消息发送者的 URL 地址，而在另一 个消息中， 个消息中，是最后一个参数表示消息发送者的 URL 地 址。 设计简单的类。类的职责要明确， 设计简单的类。类的职责要明确，不要在类中提供太 多的服务，应该从类名就可以较容易地推断出类的用途。 多的服务，应该从类名就可以较容易地推断出类的用途。
考虑如下图的设计： 考虑如下图的设计：
图1 打印输出的设计1
Hp 类、Epson 类、Canon 类分别表示不同类型的 打印机， 打印机，Output类与这 3 个类都有关联。系统运行时， 类与这 个类都有关联。系统运行时， Output类根据当前与系统相连的是哪种类型的打印机而 类根据当前与系统相连的是哪种类型的打印机而 （）方法 分别使用不同类中的 print（）方法。显然在 Output类 （）方法。 类 中会有复杂的 if...else（或 switch...case）之类的分支结 （ ） 构来判断当前与系统相连的是哪种类型的打印机。 构来判断当前与系统相连的是哪种类型的打印机。这是 一种不好的设计， 一种不好的设计，因为如果将来系统要增加一种新的打 印机类型， 打印机， 印机类型，例如 Legend 打印机，则不但要增加一个新 类的内部结构。 的 Legend 类，还要修改 Output类的内部结构。 类的内部结构
设计， 对于 OO 设计，主要是要求系统的设计结果要 能适应系统新的需求变化，一旦需求发生变化， 能适应系统新的需求变化，一旦需求发生变化， 整个系统不用做变动或做很少的变动就可以满足 新的需求。 新的需求。 OO 设计的几条原则： 设计的几条原则：
◎ ◎ ◎ ◎
开闭原则（ 开闭原则（Open/Closed Principle，OCP） ， ） Liskov替换原则（Liskov SubstitutioPrinciple，LSP） 替换原则（ 替换原则 ， ） 依赖倒置原则（ 依赖倒置原则（Dependency Inversion Principle，DIP） ， ） 接口分离原则（ 接口分离原则（Interface Segregation Principle，ISP） ， ）
在结构化设计中，高层的模块依赖于低层的模块。 在结构化设计中，高层的模块依赖于低层的模块。图 4 主程序会依赖于模块1、 中，主程序会依赖于模块 、模块 2、模块 3，而模块 1 又依 、 ， 赖于模块 11、模块 12，等等。在结构化设计中，越是低层 、 ，等等。在结构化设计中， 的模块，越跟实现细节有关，越是高层的模块越抽象， 的模块，越跟实现细节有关，越是高层的模块越抽象，但高 层的模块往往是通过调用低层的模块实现的。也就是说， 层的模块往往是通过调用低层的模块实现的。也就是说，抽 象的模块要依赖于与具体实现有关的模块， 象的模块要依赖于与具体实现有关的模块，显然这是一种不 好的依赖关系。在面向对象的设计中， 好的依赖关系。在面向对象的设计中，依赖关系正好是相反 即与具体实现有关的类是依赖于抽象类或接口， 的，即与具体实现有关的类是依赖于抽象类或接口，其依赖 所示。 关系的结构一般如图 5 所示。
三、 依赖倒置原则
依赖倒置原则指的是依赖关系应该是尽量依赖接 或抽象类），而不是依赖于具体类。 ），而不是依赖于具体类 口（或抽象类），而不是依赖于具体类。为了说明依赖 倒置原则，先看结构化设计中的依赖关系。如图 4 所示。 倒置原则，先看结构化设计中的依赖关系。 所示。
图4 结构化设计中的依赖关系
一、开闭原则
开闭原则指的是一个模块在扩展性方面应该是开放的， 开闭原则指的是一个模块在扩展性方面应该是开放的， 而在更改性方面应该是封闭的。这个原则说的是， 而在更改性方面应该是封闭的。这个原则说的是，在写模 块的时候，应该尽量使得模块可以扩展， 块的时候，应该尽量使得模块可以扩展，并且在扩展时不 需要对模块的源代码进行修改。 需要对模块的源代码进行修改。开闭原则最初是由 Bertrand Meyer提出来的［Mey88］，在所有的 OO 设计 提出来的［ ］，在所有的 提出来的 ］， 原则中，这个原则可能是最重要的。 原则中，这个原则可能是最重要的。 为了达到开闭原则的要求， 为了达到开闭原则的要求，在设计时要有意识地使用接 口进行封装，采用抽象机制， 中的多态技术。 口进行封装，采用抽象机制，并利用 OO 中的多态技术。
图3 Liskov替换原则的图示说明
的子类。 类 ClassA 要使用 ClassB，ClassC 是 ClassB 的子类。 ， 如果在运行时， 代替ClassB，则 ClassA 仍然 如果在运行时，用 ClassC 代替 ， 中提供的方法， 可以使用原来 ClassB 中提供的方法，而不需要做任何改 动。 替换原则， 利用 Liskov替换原则，在设计时可以把 ClassB 设计 替换原则 为抽象类（或接口）。 ）。让 继承抽象类（ 为抽象类（或接口）。让 ClassC 继承抽象类（或实现接 ），而 交互， 口），而 ClassA 只与 ClassB 交互，运行时 ClassC 会替 换 ClassB。这样可以保证系统有较好的可扩展性，同时 。这样可以保证系统有较好的可扩展性， 做修改。 又不需要对 ClassA 做修改。
ቤተ መጻሕፍቲ ባይዱ、接口分离原则
接口分离原则指的是在设计时采用多个与特定客户类 （ Client）有关的接口比采用一个通用的接口要好。也就是说， ）有关的接口比采用一个通用的接口要好。也就是说， 一个类要给多个客户类使用， 一个类要给多个客户类使用，那么可以为每个客户类创建一 个接口，然后这个类实现所有这些接口， 个接口，然后这个类实现所有这些接口，而不要只创建一个 接口，其中包含了所有客户类需要的方法，然后这个类实现 接口，其中包含了所有客户类需要的方法， 这个接口。 这个接口。 所示是没有采用接口分离原则的设计。 如图 6 所示是没有采用接口分离原则的设计。
设计的开闭原则。 图 1 的设计不符合 OO 设计的开闭原则。如图 2 所示是改进的设计。 所示是改进的设计。图 2 中引入了接口 Printer，其中 ， 有一个方法 print（ ）。现在 Output类只与接口 （ ）。现在 类只与接口 Printer关联，在 Output中有类型为 Printer的变量 p。 关联， 关联 中有类型为 的变量 。 不管系统与哪种类型的打印机相连， 不管系统与哪种类型的打印机相连，输出时都调用 p.print（）方法。而 p 的具体类型在运行时由系统确 （）方法 （）方法。 类型的对象， 定，可能是 Hp 类型的对象，也 可 能 是 Epson 类 型 的 对 象 或Canon 类型的对象。 类型的对象。
现在 Output类中不再有 if...else（ 或 类中不再有 （ Switch...case）之类的分支结构，而且，如果系统要 ）之类的分支结构，而且， 增加新的打印机类型，如 Legend 打印机，则只需增 增加新的打印机类型， 打印机， 加Legend 类，并且让 Legend 类实现 Printer接口即 接口即 内部不需要做任何改动。 可，而类 Output内部不需要做任何改动。因此，图 内部不需要做任何改动 因此， 2的设计具有较好的可扩展性。 的设计具有较好的可扩展性。 的设计具有较好的可扩展性
泛化结构的深度要适当。 泛化结构的深度要适当。类之间的泛化关系增加了类之间 的耦合性。除非是在特殊情况下（ 如图形用户界面的类库）， 的耦合性。除非是在特殊情况下（ 如图形用户界面的类库）， 一般不要设计有很深层次的类的泛化关系。 一般不要设计有很深层次的类的泛化关系。 定义简单的方法。一个类中的方法不应太复杂。如果一个 定义简单的方法。一个类中的方法不应太复杂。 方法太大，很可能就是这个方法包含的功能太多， 方法太大，很可能就是这个方法包含的功能太多，而有些功 能可能是不相关的。 能可能是不相关的。
图6 使用通用接口的设计
图7 使用分离接口的设计
现在对于每个客户类有一个专用的接口， 现在对于每个客户类有一个专用的接口，这个接口中 只声明了与这个客户类有关的方法， 只声明了与这个客户类有关的方法，而 ServiceImp 类实现了所有这些接口。 类实现了所有这些接口。如果 ClientA 要改变所使用 的接口中的方法， 的接口中的方法，则只需改动 ServiceA 接口和 ServiceImp 类即可，对 ClientB 和 ClientC 不会有影 类即可， 响。 当然使用这条原则并不是一定要给每个客户类创建一 个接口，在某些情况下， 个接口，在某些情况下，如果多个客户类确实需要使 用同一个接口也是可以的。 用同一个接口也是可以的。
采用这种设计方法的问题是， 采用这种设计方法的问题是，如果 ClientA 类需要改 接口中的方法， 变所使用的 Service接口中的方法，则不但要改动 Service接 接口中的方法 接 口和 ServiceImp 类，还要对 ClientB 类和 ClientC 类重新编 也就是说， 译。也就是说，对 ClientA 的修改会影响 ClientB 和 ClientC，因此图 6 的设计是一种不好的设计。 的设计是一种不好的设计。 ， 所示是采用了接口分离原则的设计。 如图 7所示是采用了接口分离原则的设计。 所示是采用了接口分离原则的设计
图5 面向对象设计中的依赖关系