[size=medium]提高系统可维护性和可复用性的设计原则[/size]
[b]1、“开-闭”原则(Open-Closed Principle,或者OCP);[/b]
一个软件实体应该对扩展开放,对修改关闭;
在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展。换言之,应当可以在不必修改源代码的情况下改变这个模块的行为。这个原则实际上是对“对可变性的封闭原则“:找到一个系统的可变因素,将之封装起来。这个原则意昧着两点:
1) 一个可变性不应当散落在代码的很多角落里,而应当被封装到一个对象里面。同一种可变性的不同表象意昧着同一个继承等级结构中的具体子类。
继承就当被看作是封装变化的方法,而不应当被认为是从一般的对象生成特殊对象的方法。
2) 一种可变性不应当与另一种可变性混合在一起。(所有类图的继承结构一般不会超过两层,不然就意昧着将两种不同的可变性混合在了一起。)
这个原则是总的原则,其它几条是这个原则的手段和工具。
[b]2、里氏替代原则(Liskov Substitution Principle,或者LSP);[/b]
如果对于每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型。
换言之,一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别。
反过来代换不成立。
[b]3、依赖倒转原则(Dependency Inversion Principle,或者DIP);[/b]
要依赖于抽象,不要依赖于具体。
开闭原则是目标,而达到这一目标的手段是依赖倒转原则。
抽象层次包含的是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定,是必然性的体现,那么抽象层次就应当是较为稳定的,应当是复用的重点;也应当是维护的重点;而具体层次则含有一些次要的与实现有关的算法和逻辑,以及战术性的决定,带有相当大的偶然性选择。具体层次的代码是会经常有变动的,不能避免出现错误。
[b]4、接口隔离原则(Interface Segregation Principle,或者ISP);[/b]
使用多个专门的接口比使用单一的总接口要好。
换言之,从一个客户类的角度讲:一个类对另一个类的依赖性应当是建立在最小的接口上的。
接口隔离原则与迪米特法则(下面讲到)都是对一个软件实体与其他的软件实体的通信限制。迪米特原则要求尽可能地限制通信的宽度和深度,接品隔离原则要求通信的宽度尽可能地窄。这样做的结果使一个软件系统在功能扩展过程当中,不会将修改的压力传递到其他对象。
一个接口相当于剧本中的一种角色,而此角色在一个舞台上由哪一个演员来演则相当于接口的实现。因此,一个接口应当简单地代表一个角色,而不是多个角色。如果系统涉及到多个角色的话,那么每一个角色都应当由一个特定的接口代表。
[b]5、组合/聚合复用原则(Composition/Aggregation Principle,或者CARP);[/b]
组合/聚合原则就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过向这些对象的委派达到得复用已有功能的目的。
要尽量使用组合/聚合,尽量不要使用继承。
[b]6、迪米特法则(Law of Demeter,或者LoD);[/b]
一个软件实体应当尽可能少的与其他实体发生相互作用。模块之间的交互要少。这样做的结果是当系统的功能需要扩展时,会相对更容易地做到对修改的关闭。
一个对象应当对其他对象有尽可能少的了解。
[b]7、单一职责原则(Single Responsibility Principle,或者SRP)[/b]
在设计中为每种职责设计一个类,彼此保持正交,互不干涉。这个原则比较容易理解,这里不在多说。
[b]1、“开-闭”原则(Open-Closed Principle,或者OCP);[/b]
一个软件实体应该对扩展开放,对修改关闭;
在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展。换言之,应当可以在不必修改源代码的情况下改变这个模块的行为。这个原则实际上是对“对可变性的封闭原则“:找到一个系统的可变因素,将之封装起来。这个原则意昧着两点:
1) 一个可变性不应当散落在代码的很多角落里,而应当被封装到一个对象里面。同一种可变性的不同表象意昧着同一个继承等级结构中的具体子类。
继承就当被看作是封装变化的方法,而不应当被认为是从一般的对象生成特殊对象的方法。
2) 一种可变性不应当与另一种可变性混合在一起。(所有类图的继承结构一般不会超过两层,不然就意昧着将两种不同的可变性混合在了一起。)
这个原则是总的原则,其它几条是这个原则的手段和工具。
[b]2、里氏替代原则(Liskov Substitution Principle,或者LSP);[/b]
如果对于每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型。
换言之,一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别。
反过来代换不成立。
[b]3、依赖倒转原则(Dependency Inversion Principle,或者DIP);[/b]
要依赖于抽象,不要依赖于具体。
开闭原则是目标,而达到这一目标的手段是依赖倒转原则。
抽象层次包含的是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定,是必然性的体现,那么抽象层次就应当是较为稳定的,应当是复用的重点;也应当是维护的重点;而具体层次则含有一些次要的与实现有关的算法和逻辑,以及战术性的决定,带有相当大的偶然性选择。具体层次的代码是会经常有变动的,不能避免出现错误。
[b]4、接口隔离原则(Interface Segregation Principle,或者ISP);[/b]
使用多个专门的接口比使用单一的总接口要好。
换言之,从一个客户类的角度讲:一个类对另一个类的依赖性应当是建立在最小的接口上的。
接口隔离原则与迪米特法则(下面讲到)都是对一个软件实体与其他的软件实体的通信限制。迪米特原则要求尽可能地限制通信的宽度和深度,接品隔离原则要求通信的宽度尽可能地窄。这样做的结果使一个软件系统在功能扩展过程当中,不会将修改的压力传递到其他对象。
一个接口相当于剧本中的一种角色,而此角色在一个舞台上由哪一个演员来演则相当于接口的实现。因此,一个接口应当简单地代表一个角色,而不是多个角色。如果系统涉及到多个角色的话,那么每一个角色都应当由一个特定的接口代表。
[b]5、组合/聚合复用原则(Composition/Aggregation Principle,或者CARP);[/b]
组合/聚合原则就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过向这些对象的委派达到得复用已有功能的目的。
要尽量使用组合/聚合,尽量不要使用继承。
[b]6、迪米特法则(Law of Demeter,或者LoD);[/b]
一个软件实体应当尽可能少的与其他实体发生相互作用。模块之间的交互要少。这样做的结果是当系统的功能需要扩展时,会相对更容易地做到对修改的关闭。
一个对象应当对其他对象有尽可能少的了解。
[b]7、单一职责原则(Single Responsibility Principle,或者SRP)[/b]
在设计中为每种职责设计一个类,彼此保持正交,互不干涉。这个原则比较容易理解,这里不在多说。