【概述】

设计原则是设计模式的理论指导，其共有 7 个，不同的设计模式遵循的原则个数各不相同。

【单一职责原则】

单一职责原则（SRP，Single Responsibility Principle）：就一个类而言，仅有一个引起它变化的原因。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

因此，难点在于如何区分职责、职责的粒度问题，而软件设计真正要做的内容，就是发现职责并把那些职责相互分离。

如果能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，此时就应该考虑类的职责分离。

单一职责不仅适用于接口、类，也同样适用于方法。

开放-封闭原则（OCP，Open-Closed Principle）：一个软件实体（类、模块、函数）应当对扩展开放，对修改关闭。

开放-封闭原则具体应用于面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本，其关键是合理地抽象、分离出变化与不变化的部分，为变化的部分预留下可扩展的方式。

而要完全遵守开闭原则是不可能的，也是没必要的，适当的抽象可以提高系统的灵活性、使其可扩展、可维护，而过度抽象，会大大增加系统的复杂程度。

其最典型的应用是钩子方法，即：对抽象方法，接口中定义方法的空实现。

例如：有一个接口，其中有 7 个方法，某一时刻只想用其中 1 个方法，那么这时，可以写一个抽象类实现这个接口，在这个抽象类里将要用的那个方法设置为 abstract，其它方法进行空实现，然后再继承这个抽象类，就不需要实现其它不用的方法。

里氏代换原则（LSP，Liskov Substitution Principle）：子类必须能够替换掉他们的父类。

只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正的被复用，而子类也能够在父类的基础上增加新的行为。

正是因为子类的可替换性，才使得父类模块在无需修改的情况下就可以扩展，从而使得开放-封闭原则成为可能。

依赖倒转原则（DIP，Dependence Inversion Principle）：高层模块不应依赖于低层模块，两者都应依赖于抽象；抽象不应依赖细节，细节应依赖于抽象。

简单来说，依赖倒转原则就是要依赖于抽象，而不是依赖于具体，针对接口编程，而不是针对实现编程。

在层次化调用的时候，潜意识中的 “ 高层调用底层的接口，底层接口的所有权在高层 ”，是一种所有权的倒置，也是一个典型的误解。

在使用传统过程化程序设计所创建的依赖关系，策略依赖于细节，是十分糟糕的，因为策略受到细节改变的影响，而依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。

在项目中如何使用：

迪米特法则（Lod，Law of Demeter）：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。一个对象应当对其它对象有尽可能少的了解。

简单来说，就是一个对象应当对其它对象有尽可能少的了解。

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

合成聚合原则（CARP，Composition Aggregation Redundancy Principle）：尽量使用合成、聚合，少使用继承。

合成聚合原则就是在新的对象中使用一些已有的对象，使之成为新对象的一部分，新的对象通过向这些对象的委派达到复用已有功能的目的。

接口隔离原则（ISP，Interface Segregation Principle）：使用多个专门的接口比使用单一的总接口要好。

从客户类的角度来讲，一个类对另一个类的依赖性应当是建立在最小接口上的，过于臃肿的接口是对接口的污染，不应该强迫客户类依赖于它们不用的方法，因此通过接口隔离原则进行多继承来分离接口，尽量的避免接口污染。