Java:设计模式七大原则整理

---

前言

面试过程中，经常被问设计模式，具体的设计模式倒是能讲两句，但是设计模式七大原则，问起来就不知道了，故而笔者想对设计模式相关原则进行一番整理,同时能够帮助笔者提升自己的编码水平

一、概念

**设计模式（Design pattern）**代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。

设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。

二、设计模式原则

1.开闭原则

核心思想是对扩展开放，对修改关闭。也就是说，对已经使用的类的改动是通过增加代码进行的，而不是修改现有代码，实现一个热插拔的效果。

例如：你手机中的桌面主题，你无法修改已有的桌面主题，只能从网上下载新的桌面主题

2.单一职责原则（Single Responsiblity Principle）

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。其实就是开发人员经常说的”高内聚，低耦合”，每个类应该只有一个职责，对外只能提供一种功能，而引起类变化的原因应该只有一个。

比如一个班级会有很多课代表，语文课代表、数学课代表、英语课代表等等，那么课代表只应该负责班级特定学科的工作，语文课代表不能插手数学课代表和英语课代表的工作。

3.里式替换原则（Liskov Substitution Principle）

里式替换的原则认为子类可以扩展父类的功能，但不能改变父类原有的功能，也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

例如鸟有一个fly() 方法，燕子是一种鸟，燕子继承鸟类并重写了 fly() 方法，企鹅是一种鸟，企鹅继承了鸟类但是企鹅不能飞，这就相当于是改变了鸟类的功能，不能说企鹅不能飞，所以鸟不能飞

4.依赖倒转原则（Dependency Inversion Principle）

依赖倒转原则的核心思想是：要依赖于抽象和接口，不要依赖于具体的实现。

其实就是说：在应用程序中，所有的类如果使用或依赖于其他的类，则应该依赖这些其他类的抽象类或者接口，而不是直接依赖这些其他类的具体类。为了实现这一原则，就要求我们在编程的时候针对抽象类或者接口编程，而不是针对具体实现编程。

例如：我们要实现监控模块，那我们更倾向于通过接口定义监控类的行为，而后调用通过代理类实现接口来调用监控类的行为，而不是直接调用监控类

5.接口分离原则（Interface Segregation Principle）

要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。

接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：

• 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
• 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

6.迪米特原则（Principle of Least Knowledge）

迪米特法则又叫最少认知原则，它的核心思想是一个对象应当对其他对象尽可能少的了解

其实就是说：降低各个对象之间的耦合，提高系统的可维护性。在模块之间应该只通过接口编程，而不理会模块的内部工作原理，它可以使各个模块耦合度降到最低，促进软件的复用。

拿我们身边的朋友圈举例子，朋友圈的确定，如果两个人有一个共同的好友，那么他们的朋友圈点赞和留言也是可见的，如果没有共同好友，那么彼此不可见。

三、设计模式分类

对于设计模式，细分可以分为三大类，和23个小类
总体来说，设计模式分为三类23种：

• 创建型（5种） ：工厂模式、抽象工厂模式、单例模式、原型模式、构建者模式
• 结构型（7种）：适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享元模式
• 行为型（11种）：模板方法模式、策略模式、观察者模式、中介者模式、状态模式、责任链模式、命令模式、迭代器模式、访问者模式、解释器模式、备忘录模式

总结

以上就是笔者关于设计模式七大原则的总结