设计模式的原则

一、单一职责原则

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

单一职责原则就是说，一个类不能太不能负责太多的功能，再简单点，就是人的器官，在每个器官的功能职责是不一样的，例如心脏就负责为人体提供血液，肺代表呼吸，在软件开发中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，就像我们前端在开发页面的时候，进行页面的组件化拆分，把颗粒度减少，每个页面组件都负责不同的工作。

demo:

从demo上可以知道People类中，承担的太多的职责了，又要供血，又要吃东西。因此应该对People这个类进行拆分，People可以拆分为一下：

Heart: 负责供血，包含supplyBlood()方法

Lung: 负责呼吸，包含breathe()方法

People: 负责走路和吃，包含eat()和walk()

二、开闭原则

开闭原则：尽量在不修改原有代码的情况下进行扩展功能。

demo:

在该demo中，如果需要增加一个新的类，如人妖 Hemophrodite，则需要修改People类的say()方法的代码，增加新的判断逻辑，原则告诉我们要对修改关闭，所以这份代码违反了开闭原则。

可以通过抽象的方式对代码进行重构，增加新的类时无须修改源代码，满足开闭原则。做法如下：

增加一个抽象人类AbstractPeople，将各种具体的人类作为子类。

PeopleSay针对抽象人类进行编程，由客户端来进行做哪一类人。

若此时需要用一个人要，仅需扩展一个 Hemophrodite 类，将 Hemophrodite 也作为 AbstractPeople 的子类即可，且无需修改其他代码。这种对扩展开放，对修改封闭就是属于开闭原则。

demo:

三、里氏代换原则

里氏代换原则：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

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

四、依赖倒转原则

依赖倒转原则：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。简单来说，设计代码之前，先不要考虑什么算法之类的实现功能，应该注重怎么利用类和方法来描述好功能的实现。

五、隔离原则

接口隔离原则：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。

六、合成复用原则

合成复用原则：尽量使用对象组合，而不是继承来达到复用的目的。

七、迪米特法则

迪米特法则：一个软件实体应当尽可能少地与其他实体发生相互作用。

如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩展会相对容易。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。