设计模式—六大原则

【内容】

1.单一职责原则（SRP）

就一个类而言，应该仅有一个引起它变化的原因。或者说一个类只负责一个功能领域中的相应职责。

单一职责原则告诉我们：如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。所以需要发现职责并把那些职责相互分离，做到一个类只负责一个功能领域的职责。这样代码才是真正的易维护、易扩展、易复用、灵活多样。

2.开放-封闭原则(Open-Closed Principle, OCP)

软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。

即对于扩展是开放的，对于更改是封闭的。软件实体应尽量在不修改原有代码的情况下进行扩展，而不做修改。

其中，对于更改是封闭的，难道就绝对不能更改吗？

不是的，绝对的对修改关闭是不可能的，无论模块是多么的‘封闭’，都会存在一些无法对之封闭的变化。

在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。

任何软件都需要面临一个很重要的问题，即它们的需求会随时间的推移而发生变化。当软件系统需要面对新的需求时，我们应该尽量保证系统的设计框架是稳定的。面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。

开放-封闭原则是面向对象设计的核心所在，好处是可维护、可扩展、可复用、灵活性好。

为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。开发人员应该仅对程序中呈现出频繁变化的那部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

3.依赖倒转原则

高层模块不应该依赖低层模块，两个都应该依赖抽象。

抽象不应该依赖细节，细节应该依赖抽象。换句话说，要针对接口编程，而不是针对实现编程。

也就是说，谁也不要依靠谁，除了约定的接口，大家都可以灵活自如。

在引入抽象层后，系统将具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改配置文件，而无须修改原有系统的源代码，在不修改的情况下来扩展系统的功能，满足开闭原则的要求。

4.里氏代换原则

子类型必须能够替换掉它们的父类型。

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。

里氏代换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。例如：我喜欢动物，那我一定喜欢狗，因为狗是动物的子类；但是我喜欢狗，不能据此断定我喜欢动物，因为我并不喜欢老鼠，虽然它也是动物。

里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

5.迪米特法则（LoD）

也称最少知识原则，如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。一个软件实体应当尽可能少地与其他实体发生相互作用。

迪米特原则强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限。也就是说，一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不需要公开。

迪米特法则的根本思想是强调了类之间的松耦合。在程序设计时，类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及，也就是说，信息的隐藏促进了软件的复用。

6.合成/聚合复用原则（CARP）

尽量使用合成/聚合，尽量不要使用类继承。

合成和聚合都是关联的特殊种类。聚合表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；合成则是一种强的‘拥有’关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。

比如，大雁有两个翅膀，翅膀和大雁是部分和整体的关系，并且它们的生命周期是相同的，于是大雁和翅膀就是合成关系。而大雁是群居动物，所以每只大三都是属于一个雁群，一个雁群可以有多只大雁，所以大雁和雁群是聚合关系。

合成/聚合复用原则的好处是优先使用对象的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上，这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。

补充：接口隔离原则(Interface  Segregation Principle, ISP)

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。这里的“接口”往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的“接口”定义，有严格的定义和结构。

举例：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类C来说不是最小接口，则类B和类D必须去实现他们不需要的方法。将接口I拆分成独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。