1 繁多职责准则
1.1 定义
不要存在多于一个导致类变更的起因。
1.2 名词解释
艰深的说，即一个类只负责一项职责。
1.3 场景阐明
如果类 T 负责两个不同的职责：职责 P1，职责 P2。当因为职责 P1 需要产生扭转而须要批改类 T 时，有可能会导致本来运行失常的职责 P2 性能产生故障。
解决形式 ：遵循繁多职责准则。别离建设两个类 T1、T2，使 T1 实现职责 P1 性能，T2 实现职责 P2 性能。这样，当批改类 T1 时，不会使职责 P2 产生故障危险；同理，当批改 T2 时，也不会使职责 P1 产生故障危险。
1.4 长处
- 能够升高类的复杂度，一个类只负责一项职责，其逻辑必定要比负责多项职责简略的多；
- 进步类的可读性，进步零碎的可维护性
- 变更引起的危险升高，变更是必然的，如果繁多职责准则恪守的好，当批改一个性能时，能够显著升高对其余性能的影响。
2 里氏替换准则
2.1 定义
（1）如果对每一个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
（2）所有援用基类的中央必须能通明地应用其子类的对象。
2.2 名词解释
里氏替换准则艰深的来讲就是：子类能够扩大父类的性能，但不能扭转父类原有的性能。它蕴含以下 4 层含意：
- 子类能够实现父类的形象办法，但不能笼罩父类的非形象办法。
- 子类中能够减少本人特有的办法。
- 当子类的办法重载父类的办法时，办法的前置条件（即办法的形参）要比父类办法的输出参数更宽松。
- 当子类的办法实现父类的形象办法时，办法的后置条件（即办法的返回值）要比父类更严格。
2.3 场景阐明
有一性能 P1，由类 A 实现。现须要将性能 P1 进行扩大，扩大后的性能为 P，其中 P 由原有性能 P1 与新性能 P2 组成。新性能 P 由类 A 的子类 B 来实现，则子类 B 在实现新性能 P2 的同时，有可能会导致原有性能 P1 产生故障。
解决形式 ：当应用继承时，遵循里氏替换准则。类 B 继承类 A 时，除增加新的办法实现新增性能 P2 外，尽量不要重写父类 A 的办法，也尽量不要重载父类 A 的办法。
3 依赖倒置
3.1 定义
高层模块不应该依赖低层模块，二者都应该依赖其形象；形象不应该依赖细节；细节应该依赖形象。
3.2 名词解释
依赖倒置准则的核心思想是面向接口编程。在理论编程中，个别须要做到如下 3 点：
- 低层模块尽量都要有抽象类或接口，或者都有。
- 变量的申明类型尽量是抽象类或接口。
- 应用继承时遵循里氏替换准则。
3.3 场景阐明
类 A 间接依赖类 B，如果要将类 A 改为依赖类 C，则必须通过批改类 A 的代码来达成。这种场景下，类 A 个别是高层模块，负责简单的业务逻辑；类 B 和类 C 是低层模块，负责根本的原子操作；如果批改类 A，会给程序带来不必要的危险。
解决形式： 将类 A 批改为依赖接口 I，类 B 和类 C 各自实现接口 I，类 A 通过接口 I 间接与类 B 或者类 C 产生分割，则会大大降低批改类 A 的几率。
4 接口隔离准则
4.1 定义
客户端不应该依赖它不须要的接口；一个类对另一个类的依赖应该建设在最小的接口上。
4.2 名词解释
接口隔离准则次要束缚接口，次要针对程序整体框架的形象构建。
采纳接口隔离准则对接口进行束缚时，要留神以下几点：
- 接口尽量小，然而要有限度。对接口进行细化能够进步程序设计灵活性是不挣的事实，然而如果过小，则会造成接口数量过多，使设计复杂化。所以肯定要适度。
- 为依赖接口的类定制服务，只裸露给调用的类它须要的办法，它不须要的办法则暗藏起来。只有专一地为一个模块提供定制服务，能力建设最小的依赖关系。
- 进步内聚，缩小对外交互。使接口用起码的办法去实现最多的事件。
使用接口隔离准则，肯定要适度，接口设计的过大或过小都不好
4.3 场景阐明
类 A 通过接口 I 依赖类 B，类 C 通过接口 I 依赖类 D，如果接口 I 对于类 A 和类 B 来说不是最小接口，则类 B 和类 D 必须去实现他们不须要的办法。
解决形式 ：将臃肿的接口 I 拆分为独立的几个接口，类 A 和类 C 别离与他们须要的接口建设依赖关系。也就是采纳接口隔离准则。
5 迪米特准则
5.1 定义
一个对象应该对其余对象放弃起码的理解。
5.2 名词解释
迪米特法令的初衷是升高类之间的耦合，因为每个类都缩小了不必要的依赖，因而确实能够升高耦合关系。然而凡事都有度，尽管能够防止与非间接的类通信，然而要通信，必然会通过一个“中介”来产生分割，过分的应用迪米特准则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采纳迪米特法令时要重复衡量，既做到构造清晰，又要高内聚低耦合。
5.3 场景阐明
类与类之间的关系越亲密，耦合度越大，当一个类产生扭转时，对另一个类的影响也越大。
解决形式 ：尽量升高类与类之间的耦合。
6 开闭准则
6.1 定义
一个软件实体如类、模块和函数应该对扩大凋谢，对批改敞开。
6.2 名词解释
用形象构建框架，用实现扩大细节。因为形象灵活性好，适应性广，只有形象的正当，能够根本放弃软件架构的稳固。而软件中易变的细节，用从抽象派生的实现类来进行扩大，当软件须要发生变化时，只须要依据需要从新派生一个实现类来扩大就能够了。当然前提是形象要正当，要对需要的变更有前瞻性和预见性。
6.3 场景阐明
在软件的生命周期内，因为变动、降级和保护等起因须要对软件原有代码进行批改时，可能会给旧代码中引入谬误，也可能会使咱们不得不对整个性能进行重构，并且须要原有代码通过从新测试。
解决形式 ：当软件须要变动时，尽量通过扩大软件实体的行为来实现变动，而不是通过批改已有的代码来实现变动。