【六大设计原则】

SOLID，稳定的。

1、单一职责原则（Single Responsibility Principle - SRP）

一个类只负责一个功能领域中的相应职责，只有一个引起它变化的原因。
eg.业务对象，业务逻辑拆分。可以看做是低耦合，高内聚在面向对象原则上的引申。

2、开放封闭原则（Open Closed Principle - OCP）

一个软件实体（如类，模块和函数）应当对扩展开放，对修改封闭。
即软件实体应尽量在不修改原有代码的情况下进行扩展。总结为：用抽象构建架构，用实现来进行扩展。设计模式中的策略模式和模板模式就是在实现这个原则。

3、里氏替换原则（Liskov Substitution Principle - LSP）

所有引用基类的地方必须能透明地使用其子类的对象。
即子类可以扩展父类的功能，但不能改变原有父类的功能。在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。
简单来说，所有使用基类代码的地方，如果换成子类对象的时候还能够正常运行，则满足这个原则，否则就是继承关系有问题，应该废除两者的继承关系，这个原则可以用来判断我们的对象继承关系是否合理。

4、最少知识原则（Least Knowledge Principle - LKP）— 也叫迪米特原则（law of demeter LOD）

一个软件实体应当尽可能少地与其他实体发生相互作用。（不属于SOILD原则）
在迪米特法则中，对于一个对象，其朋友包括以下几类：

  1. 当前对象本身(this)；
  2. 以参数形式传入到当前对象方法中的对象；
  3. 当前对象的成员对象；
  4. 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友；
  5. 当前对象所创建的对象。

    5、接口隔离原则（Interface Segregation Principle - ISP）

    不能强迫用户去依赖那些他们不使用的接口。
    简单来说就是客户端需要什么接口，就提供给它什么样的接口，其它多余的接口就不要提供，不要让接口变得臃肿，否则当对象一个没有使用的方法被改变了，这个对象也将会受到影响。接口的设计应该遵循最小接口原则，其实这也是高内聚的一种表现，换句话说，使用多个功能单一、高内聚的接口总比使用一个庞大的接口要好。

    6、依赖倒置原则（Dependence Inversion Principle - DIP）

    高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
    其实这就是我们经常说的“面向接口编程”，这里的接口就是抽象，我们应该依赖接口，而不是依赖具体的实现来编程。
    依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。

    【其他设计原则】

    1、组合/聚合复用原则（Composition/Aggregation Reuse Principle - CARP）

    当要扩展类的功能时，优先考虑使用组合，而不是继承。这条原则在 23 种经典设计模式中频繁使用，如：代理模式、装饰模式、适配器模式等。可见江湖地位非常之高！

    2、无环依赖原则（Acyclic Dependencies Principle - ADP）

    当 A 模块依赖于 B 模块，B 模块依赖于 C 模块，C 依赖于 A 模块，此时将出现循环依赖。在设计中应该避免这个问题，可通过引入“中介者模式”解决该问题。

    3、共同封装原则（Common Closure Principle - CCP）

    应该将易变的类放在同一个包里，将变化隔离出来。该原则是“开放-封闭原则”的延生。

    4、共同重用原则（Common Reuse Principle - CRP）

    如果重用了包中的一个类，那么也就相当于重用了包中的所有类，我们要尽可能减小包的大小。

    5、好莱坞原则（Hollywood Principle - HP）

    好莱坞明星的经纪人一般都很忙，他们不想被打扰，往往会说：Don’t call me, I’ll call you. 翻译为：不要联系我，我会联系你。对应于软件设计而言，最著名的就是“控制反转”（或称为“依赖注入”），我们不需要在代码中主动的创建对象，而是由容器帮我们来创建并管理这些对象。

    【其他设计原则】

    1、不要重复你自己（Don’t repeat yourself - DRY）

    不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能地封装。

    2、保持它简单与傻瓜（Keep it simple and stupid - KISS）

    不要让系统变得复杂，界面简洁，功能实用，操作方便，要让它足够的简单，足够的傻瓜。

    3、高内聚与低耦合（High Cohesion and Low Coupling - HCLC）

    模块内部需要做到内聚度高，模块之间需要做到耦合度低。

    4、惯例优于配置（Convention over Configuration - COC）

    尽量让惯例来减少配置，这样才能提高开发效率，尽量做到“零配置”。很多开发框架都是这样做的。

    5、命令查询分离（Command Query Separation - CQS）

    在定义接口时，要做到哪些是命令，哪些是查询，要将它们分离，而不要揉到一起。

    6、关注点分离（Separation of Concerns - SOC）

    将一个复杂的问题分离为多个简单的问题，然后逐个解决这些简单的问题，那么这个复杂的问题就解决了。难就难在如何进行分离。

    7、契约式设计（Design by Contract - DBC）

    模块或系统之间的交互，都是基于契约（接口或抽象）的，而不要依赖于具体实现。该原则建议我们要面向契约编程。

    8、你不需要它（You aren’t gonna need it - YAGNI）

    不要一开始就把系统设计得非常复杂，不要陷入“过度设计”的深渊。应该让系统足够的简单，而却又不失扩展性，这是其中的难点。