设计模式-六大原则

概述

设计模式体现的是软件设计的思想，而不是软件技术，它重在使用接口与抽象类来解决各种问题。在使用这些设计模式时，应该首先遵守六大原则。

一、开闭原则(Open Closed Principle)

通常，对于开发完的代码都需要多种测试才能够投入使用，这包括：

• 首先要经过开发人员的单元测试、集成测试。
• 然后再到测试人员的白盒测试、黑盒测试。
• 最后还要由用户进行一定的测试。

经过漫长的测试，代码才能够投入使用。但是软件产品的维护和升级又是一个永恒的话题，在维护的过程中，你可能要不断地增加一些小功能:在升级的过程中，你要增加一些较大的功能。

因此，软件产品随时都有扩展功能的要求。这种功能的扩展，就要求我们改变原有的代码。但是，对原代码的修改就会深刻地影响到原来的功能的方方面面：

• 可能对旧代码引入了新的错误，使你不得不对旧代码进行大规模的修改。
• 可能引起你不得不重新构造系统的架构。
• 即使新增的代码对旧代码没有影响，你也不得不对原来的系统做一个全面的测试。

所有上述列出来的问题，都是对系统功能进行扩展所不能承受的代价。换句话说，我们设计出来的系统，一定要是扩展性良好的系统。如何才能够设计出扩展性良好的系统呢?这就需要在软件系统设计时遵守开闭原则：系统必须对扩展开发，对修改关闭。

做到开闭原则，就注意以下两点：
1)多使用抽象类
在设计类时，对于拥有共同功能的相似类进行抽象化处理，将公用的功能部分放到抽象类中，所有的操作都调用子类。这样，在需要对系统进行功能扩展时，只需要依据抽象类实现新的子类即可。如图10-1所示，在扩展子类时，不仅可以拥有抽象类的共有属性和共有函数，还可以拥有自定义的属性和函数。

2)多使用接口
与抽象类不同，接口只定义子类应该实现的接口函数，而不实现公有的功能。在现在大多数的软件开发中，都会为实现类定义接口，这样在扩展子类时实现该接口。如果要改换原有的实现，只需要改换一个实现类即可。如图10-2所示，各子类由接口类定义了接口函数，只需要在不同的子类中编写不同的实现即可，当然也可以实现自有的函数。

以上两点将会在后续的各个设计模式中得到充分的体现。

二、里氏代换原则(Liskov Substitution Principle)

里氏代换原则：子类必须能够替换成它们的基类。

在一个软件系统中，子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。子类也能够在基类的基础上增加新的行为。

里氏代换原则是对开闭原则的补充，它讲的是基类和子类的关系。只有当这种关系存在时，里氏代换关系才存在。

三、依赖倒转原则(Dependence Inversion Principle)

开闭原则的主要机制就是依赖倒转原则，这个原则的内容是：要依赖于抽象，不要依赖于具体。即要针对接口编程，不针对实现编程。

依赖也就是耦合，共分为下面3种。

• 零耦合(NilCoupling)关系：两个类没有依赖关系。
• 具体耦合(Concrete Coupling)关系：两个具体的类之间有依赖关系，如果一个具体类直接引用另外一个具体类，就是这种关系。
• 抽象耦合(AbstractCoupling)关系：这种关系发生在一个具体类和一个抽象类之间，这样就使必须发生关系的类之间保持最大的灵活性。

依赖倒转原则要求客户端依赖于抽象耦合，抽象不应当依赖于细节，细节应当依赖于抽象。这个原则的另外一个表述就是:要针对接口编程，不要对实现编程。程序在需要引用一个对象时，应当尽可能地使用抽象类型作为变量的静态类型，这就是针对接口编程的含义。依赖倒转原则是达到开闭原则的途径。

要做到依赖倒转原则，使用抽象方式耦合是关键。由于一个抽象耦合总要涉及具体类从抽象类继承，并且需要保证在任何引用到某类的地方都可以改换成其子类，因此，里氏代换原则是依赖倒转原则的基础,依赖倒转原则是OOD的核心原则,设计模式的研究和应用都是用它作为指导原则的。

四、接口隔离原则(Interface Segregation Principle)

接口隔离原则的意思是：使用多个隔离的接口，比使用单个接口好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上的。

在我们进行设计的时候，一个重要的工作就是恰当地划分角色和角色对应的接口。因此，这里的接口往往有两种不同的含义。

1.接口对应的角色
指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象，接口的划分就直接带来类型的划分。这里，我们可以把接口理解成角色，一个接口只是代表一个角色，每个角色都有它特定的一个接口，这里的这个原则可以叫做角色隔离原则。

2.角色对应的接口
指某种语言具体的接口定义，有严格的定义和结构。比如Java语言里面的Interface 结构。对不同的客户端，同一个角色提供宽窄不同的接口，也就是定制服务，仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来。

对接口角色的划分，是从大的类上进行划分的：对角色的接口进行的划分，是对类的接口函数的划分。它们两者由粗到细，实现了接口的完全分离。

五、迪米特法则(最少知道原则)(Demeter Principle)

迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在(或很少有)依赖关系。

迪米特法则不希望类直接建立直接的接触。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系–这在一定程度上增加了系统的复杂度。

例如，购房者要购买楼盘 A、B、C中的楼，他不必直接到楼盘去买楼，而是可以通过一个售楼处去了解情况，这样就减少了购房者与楼盘之间的耦合，如图10-6所示。

六、合成复用原则(Composite Reuse Principle)

合成(Composition)和聚合(Aggregation)都是关联(Association)的特殊种类。聚合表示整体和部分的关系，表示“拥有”;合成则是一种更强的“拥有”，部分和整体的生命周期一样。合成的新的对象完全支配其组成部分，包括它们的创建和销毁等。一个合成关系的成分对象是不能与另个合成关系共享的。

在面向对象设计中，有两种基本的办法可以实现复用：

• 第一种是通过合成/聚合，即合成复用原则，含义是指，尽量使用合成/聚合，而不是使用继承。
• 第二种就是通过继承。

要正确地选择合成/复用和继承的方法是，只有当以下的条件全部被满足时，才应当使用继承关系。

• 子类是超类的一个特殊种类，而不是超类的一个角色，也就是区分“Has-A”和“Is-A”只有“IS-A”关系才符合继承关系，“Has-A”关系应当用聚合来描述。
• 永远不会出现需要将子类换成另外一个类的子类的情况。如果不能肯定将来是否会变成另外一个子类的话，就不要使用继承。
• 子类具有扩展超类的责任，而不是具有置换掉(override)或注销掉(Nullify)超类的责任如果一个子类需要大量的置换掉超类的行为，那么这个类就不应该是这个超类的子类。
• 只有在分类学角度上有意义时，才可以使用继承。不要从工具类继承。