设计模式六大原则

六大原则简述：

单一职责原则：实现类/方法职责单一；
开闭原则：要对扩展开放，对修改旧代码关闭。
里氏替换原则：不要破坏继承体系；
依赖倒置原则：要面向接口编程；
接口隔离原则：在设计接口要精简单一；
迪米特原则：要降低耦合；

六大原则目的:为了构建灵活、可扩展、可维护的软件系统，它的重要性高于设计模式的，设计模式只是它的具体实践。

（1）单一职责原则

定义：一个类只负责一个功能领域中的相应职责。就一个类而言，应该只有一个引起它变化的原因。
问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
理解：一个类/接口/模块/方法承担的职责要尽量小（职责解偶），这样才可能复用已有代码。但是，当多个职责因一个原因发生改变时，多个职责应封装在一起。
理论指导：

某一变化只影响其中一个职责，单一职责拆为独立类/方法。
某一变化影响到多个职责，多个职责可以封装在一起。

优点：

• 降低类的复杂度。一个类只负责一项职责，其逻辑比负责多项职责简单；
• 提高类的可读性，提高系统的可维护性；
• 降低类变更引起的风险。

（2）开闭原则

定义：一个软件实体应当可扩展，不可修改原代码。即软件实体应尽量在不修改原有代码的情况下进行扩展。
问题由来：需求改变时，修改旧代码可能导致旧代码错误，还要重新测试。因此，当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码实现。
理论指导:

• 尽可能对系统进行抽象化设计，为系统定义一个相对稳定的抽象层。
• 具体实现行为在实现层中完成，此时修改系统行为，无需修改旧代码只需新增实现类来实现新的业务功能，达到开闭原则的要求。

（3）里氏代换原则

定义：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
理解：一个软件系统中所有用到一个类的地方都替换成其子类，系统应该仍然可以正常工作，反之不可。这个原则依赖继承和多态，一定是面向抽象（接口）编程。

（4）依赖倒置原则

定义：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

关键点：

1. 高层模块不应该依赖低层模块，两者都应该依赖其抽象
2. 抽象不应该依赖细节
3. 细节应该依赖抽象

（5）接口隔离原则

定义：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
目的:让调用者依赖的接口尽可能小。例如人类分男人和女人，男人和女人都要吃饭，但只有女人每个月来大姨妈，如果设计接口里面除了吃饭还有来大姨妈同时给男人和女人用就不合适了。

（6）迪米特原则

定义:又称最少知识原则。一个软件实体应当尽可能少地与其他实体发生相互作用。
理解:一个类应该对自己需要调用的类知道得最少。即被调用类内部如何实现都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。

引用链接