在做架构设计的过程中，设计原则是我们的软件设计准则。有了这一准则，我们在软件设计的路上才不会偏离轨道太远。

单一原则

定义

就一个类而言，应该仅有一个引起它变化的原因。简单来说就是一个类中应该是一组相关性很高的函数、数据的封装。

开闭原则

定义

在软件中的对象应该对于扩展是开发的，但是对于修改是封闭的。

目的

让程序更稳定、更灵活。

场景

• 在软件开发过程中，最不会变化的就是变化本身。产品在升级过程中，如果直接修改原来的代码有可能会引起未知的问题。那么，如何确保原有模块的正确性，以及尽量少地影响原有的模块，答案就是尽量遵守开闭原则。

里氏替换原则

定义

所有引用基类的地方必须能透明地使用其子类的对象。这句话的意思是说在基类出现的地方子类就可以出现，而且替换为子类也不会有任何异常。但是反过来就不行了，有子类出现的地方，父类未必就合适出现。

目的

构建扩展性更好的系统，里氏替换原则和开闭原则往往是生死相依、不离不弃的，通过里氏替换原则来达到对扩展开放，对修改关闭的效果。

场景

在使用类继承的时候，抽象是依赖继承这个特性，里氏替换原则的核心是抽象。可以说里氏替换原则是对继承定义了一个规范。
在软件设计的时候，使用继承的是，就应该想到里氏替换原则。

依赖倒转原则

定义

高层模块不依赖于低层模块的实现细节，依赖模块被颠倒了。依赖倒置原则则指代了一种特定的解耦方式。
依赖倒置原则的关键点：

• 高层模块不应该依赖于低层模块，两者都应该依赖其抽象；
• 抽象不应该依赖细节，细节应该依赖抽象。

目的

让项目拥有变化的能力。

场景

高层模块是调用端，低层模块就是具体的实现类。模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或者抽象类来产生的。

迪米特原则

定义

一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信，不和陌生人说话。迪米特原则又叫最少知道原则。

目的

用来降低类之间的耦合。

场景

中介模式体现了迪米特原则。类与类之间通过一个中介者来解耦，我个人的理解，在一定程度上是解耦了，但是软件中可能会多出来很多中介类。

接口隔离原则

定义

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

目的

让系统解耦，有更高的灵活性。

场景

提供调用者需要的方法，屏蔽不需要的方法。