面向对象设计的设计原则

      “对可变性的封装原则”意味着：

　　a) 一种可变性不应当散落在代码的许多角落，而应当被封装到一个工具内里。统一可变性的差别表象意味着统一个继续品级结构中的详细子类。因此，此处可以期待继续关系的泛起。继续是封装转变的要领，而不仅仅是从一样平常的工具天生特殊的工具。

　　b) 一种可变性不应当与另一种可变性混淆在一起。作者以为类图的继续结构若是凌驾两层，很可能意味着两种差别的可变性混淆在了一起。

　　使用“可变性封装原则”来举行设计可以使系统遵守“开-闭”原则。

　　纵然无法百分之百的做到“开-闭”原则，但朝这个偏向起劲，可以显著改善一个系统的结构。

　　二、里氏代换原则（Liskov Substitution Principle, LSP）

　　2.1 观点

　　界说：若是对每一个类型为 T1 的工具 O1 ，都有类型为 T2 的工具 O2 ，使得以 T1 界说的所有程序 P 在所有的工具 O1 都代换为 O2 时，程序 P 的行为没有转变，那么类型 T2 是类型 T1 的子类型。

　　即，一个软件实体若是使用的是一个基类的话，那么一定适用于其子类。而且它觉察不出基类工具和子类工具的区别。 也就是说，在软件内里，把基类都替换成它的子类，程序的行为没有转变。

　　反过来的代换不建立，若是一个软件实体使用的是一个子类的话，那么它纷歧定适用于基类。

　　任何基类可以泛起的地方，子类一定可以泛起。

　　基于左券的设计、抽象出公共部门作为抽象基类的设计。

　　2.2 里氏代换原则与“开- 闭” 原则的关系

　　实现“开-闭”原则的要害步骤是抽象化。基类与子类之间的继续关系就是抽象化的体现。因此里氏代换原则是对实现抽象化的详细步骤的规范。

　　违反里氏代换原则意味着违反了“开-闭”原则，反之未必。

　　三、 依赖倒转原则 （ dependence inversion principle, DIP ）

　　3.1 观点

　　依赖倒转原则就是要依赖于抽象，不要依赖于实现。（Abstractions should not depend upon details. Details should depend upon abstractions.）要针对接口编程，不要针对实现编程。（Program to an interface, not an implementation.）

　　也就是说应当使用接口和抽象类举行变量类型声明、参数类型声明、要领返还类型说明，以及数据类型的转换等。而不要用详细类举行变量的类型声明、参数类型声明、要领返还类型说明，以及数据类型的转换等。要保证做到这一点，一个详细类应当只实现接口和抽象类中声明过的要领，而不要给出多余的要领。

　　传统的历程性系统的设计措施倾向于使高条理的模块依赖于低条理的模块，抽象条理依赖于详细条理。倒转原则就是把这个错误的依赖关系倒转过来。

　　面向工具设计的主要原则是建立抽象化，而且从抽象化导出详细化，详细化给出差别的实现。继续关系就是一种从抽象化到详细化的导出。

　　抽象层包罗的应该是应用系统的商务逻辑和宏观的、对整个系统来说主要的战略性决议，是一定性的体现。详细条理含有的是一些次要的与实现有关的算法和逻辑，以及战术性的决议，带有相当大的无意性选择。详细条理的代码是经常变更的，不能制止泛起错误。

　　从复用的角度来说，高条理的模块是应当复用的，而且是复用的重点，由于它含有一个应用系统最主要的宏观商务逻辑，是较为稳固的。而在传统的历程性设计中，复用则偏重于详细条理模块的复用。

　　依赖倒转原则则是对传统的历程性设计要领的“倒转”，是高条理模块复用及其可维护性的有用规范。

　　特例：工具的建立历程是违反“开—闭”原则以及依赖倒转原则的，但通过工厂模式，能很好地解决工具建立历程中的依赖倒转问题。

　　3.2 关系

　　“开-闭”原则与依赖倒转原则是目的和手段的关系。若是说开闭原则是目的，依赖倒转原则是到达"开闭"原则的手段。若是要到达最好的"开闭"原则，就要只管的遵守依赖倒转原则，依赖倒转原则是对"抽象化"的最好规范。

 2/6   首页 上一页 1 2 3 4 5 6 下一页 尾页