设计模式的七大设计原则

---

前言

设计模式就是为了让程序具有更好的 ：

• 代码重用性（相同功能的代码，不用多次编写）
• 可读性（编程规范性，便于其他程序员的阅读和理解）
• 可扩展性（当需要增加新的功能时，非常的方便，称为可维护）
• 可靠性（当我们增加新的功能后，对原来的功能没有影响）
• 使程序呈现高内聚，低耦合的特性。

---

一、单一职责原则

• 即一个类，接口，方法 只负责一项职责
• 这样的设计可以提高代码的可读性，降低代码的复杂度，最主要的是降低了每次变更引起的风险。
• 主要是避免修改方法之后，对多处调用的地方产生影响。
• 通常情况下，我们应当遵守单一职责原则。只有在逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，才可以在方法级别保持单一原则。

二、接口隔离原则

即用多个专门的接口,而不是用单一的总接口,客户端不应该依赖它不需要的接口。
因此这个原则需要我们在设计接口时应当注意一下几点 ：
1、一个类对一个类的依赖应该建立在最小的接口之上。
2、建立单一接口,不要建立庞大臃肿的接口。
3、尽量细化接口,接口中的方法尽量少(不是越少越好,一定要适度)。
我们在设计接口的时候,要多花时间去思考,要考虑业务模型,包括以后有可能发生变更的地方还要做一些预判。

三、依赖倒置原则

即 :

• 高层模块不应该依赖低层模块，二者都应该依赖其抽象
• 抽象不应该依赖细节，细节应该依赖抽象
• 依赖倒置的中心思想是面向接口编程
• 依赖倒转原则是基于的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽指的是接口或抽象类，细节就是具体的实现类
• 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

四、里式替换原则

即 ：

• 子类对象无论何时都能替换父类对象
• 子类可以扩展父类的功能，但不能改变父类原有的功能。
• 里氏替换原则是描述了父子类之间继承的规则。

五、开闭原则（OCP原则）

即 ：

• 开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则
• 一个软件实体如 ： 类，模块和函数应该对扩展(提供方)开放，对修改（使用方)关闭。用抽象构建框架，用实现扩展细节。
• 当软件需要变化时，尽量 通过扩展软件实体的行为来实现变化，而 不是通过修改已有的代码来实现变化。

六、迪米特法则（最少知道原则）

即 ：

• 迪米特法则(Demeter Principle)又叫 最少知道原则，即一个类对自己所依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public 方法，不对外泄露任何细节信息。
• 两个实体间无需直接通信，可以通过第三方进行间接调用。
• 迪米特法则还有一个更简单的定义：只与直接的朋友通信。
• 直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。我们称出现成员变量、方法参数、方法返回值中的类为直接朋友，而出现在局部变量中的类不是直接朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

七、合成复用原则

即 ：

• 尽量使用对象组合/聚合,而不是继承关系达到软件复用的目的。可以使系统更加灵活,降低类与类之间的耦合度,一个类的变化对其他类造成的影响相对较少。
• 继承我们叫做白箱复用,相当于把所有的实现细节暴露给子类。
• 组合/聚合也称之为黑箱复用,对类以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计,其实也都需要遵循OOP模型。

---

总结

其实在实际开发过程中,并不是一定要求所有代码都遵循设计原则,因为我们还要考虑人力、时间、成本、质量等因素,要在适当的场景遵循设计原则,体现的是一种平衡取舍,帮助我们设计出更加优雅的代码结构。