提高系统可维护性和可复用性的设计原则

[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]

在设计中为每种职责设计一个类，彼此保持正交，互不干涉。这个原则比较容易理解，这里不在多说。