设计模式遵守的七大设计原则

文章目录

• 什么是设计模式？
• • 1、设计模式的定义
  • 2、设计模式的分类
  • • (1)、创建型模式：
    • (2)、结构型模式:
    • (3)、行为型模式
  • 3、设计模式七大原则
  • • 一、开放封闭原则(OCP)
    • 二、单一职责原则(SRP)
    • 三、依赖倒转(倒置)原则(DIP)
    • 四、里氏代换原则(LSP)
    • 五、接口分离原则(ISL)
    • 六、迪米特原则(LOD)
    • 七、合成复用原则(CARP)
    • 七个原则总结：

什么是设计模式？ 1、设计模式的定义

设计模式是对软件设计中反复出现的各种问题，所提出的解决方案，它并不直接用来完成代码的编写，而是描述在各种不同的情况下，要怎么解决问题的一种方案。通过设计模式可以帮助我们增强代码的可重用性、可扩充性、可维护性、灵活性等，我们使用设计模式的最终的目的是实现代码的高内聚和低耦合。

2、设计模式的分类

设计模式一共有23种，大体分为创建型、行为型、结构型三大类。

(1)、创建型模式：

对象实例化的模式，创建型模式用于解耦对象的实例化过程。

1. 单例模式：某个类智能有一个实例，提供一个全局的访问点。
2. 工厂模式：一个工厂类根据传入的参量决定创建出哪一种产品类的实例。
3. 抽象工厂模式：创建相关或依赖对象的家族，而无需明确指定具体类。
4. 建造者模式：封装一个复杂对象的创建过程，并可以按步骤构造。
5. 原型模式：通过复制现有的实例来创建新的实例。

(2)、结构型模式:

把类或对象结合在一起形成一个更大的结构。

1. 装饰器模式：动态的给对象添加新的功能。
2. 代理模式：为其它对象提供一个代理以便控制这个对象的访问。
3. 桥接模式：将抽象部分和它的实现部分分离，使它们都可以独立的变化。
4. 适配器模式：将一个类的方法接口转换成客户希望的另一个接口。
5. 组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构。
6. 外观模式：对外提供一个统一的方法，来访问子系统中的一群接口。
7. 享元模式：通过共享技术来有效的支持大量细粒度的对象。

(3)、行为型模式

类和对象如何交互，及划分责任和算法。

1. 策略模式：定义一系列算法，把他们封装起来，并且使它们可以相互替换。
2. 模板模式：定义一个算法结构，而将一些步骤延迟到子类实现。
3. 命令模式：将命令请求封装为一个对象，使得可以用不同的请求来进行参数化。
4. 迭代器模式：一种遍历访问聚合对象中各个元素的方法，不暴露该对象的内部结构。
5. 观察者模式：对象间的一对多的依赖关系。
6. 仲裁者模式：用一个中介对象来封装一系列的对象交互。
7. 备忘录模式：在不破坏封装的前提下，保持对象的内部状态。
8. 解释器模式：给定一个语言，定义它的文法的一种表示，并定义一个解释器。
9. 状态模式：允许一个对象在其对象内部状态改变时改变它的行为。
10. 责任链模式：将请求的发送者和接收者解耦，使的多个对象都有处理这个请求的机会。
11. 访问者模式：不改变数据结构的前提下，增加作用于一组对象元素的新功能。

原文链接

3、设计模式七大原则 一、开放封闭原则(OCP)

开放封闭原则(Open-ClosedPrincinple,简称OCP)：

​ 一个模块、类、函数应当是对修改关闭，对扩展开放。在不修改源代码的情况下进行扩展。

• ​ 修改原有的代码可能会造成原来正常的功能出现问题。
• ​ 当需求有变，可以通过扩展来实现，增加新的方法或者属性。

开闭原则是最基础的设计原则，也是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。其它的设计原则都是开闭原则的具体形态，如果用面向对象的思想阐述，开闭原则是最顶层的抽象类，其它五个类则是对它的具体实现。

---

二、单一职责原则(SRP)

单一职责原则(Single Responsibility Principle ,简称SRP):

就一个类而言，应该仅有一个引起它变化的原因。每个类应该实现单一的原则，否则就应该把类拆分。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。

简单的来说，类的功能要单一，不能包罗万象，跟杂货铺一样。

---

三、依赖倒转(倒置)原则(DIP)

依赖倒置原则(Dependence Inversion Principle ,简称DIP ):

是开闭原则的基础，具体内容是针对接口编程，依赖于抽象而不依赖于具体。

1、高层模块不应该依赖底层模块，两个都应该依赖抽象。

2、抽象不应该依赖细节，细节应该依赖抽象(ASD)

第一句话，可以这么理解：比如，用户的登录与注册模块，具体实现流程是前端把表单提交给后端，后端再根据表单中的数据对数据库进行读写 *** 作。在用java访问数据库的过程中，我们都会使用JDBC，先写好一个封装好对数据库访问的函数(底层函数)，之后具体的业务逻辑(高层函数)再调用这个函数，这种叫高层模块依赖底层模块。这种方式会造成不能复用高层模块，因为高层模块都是和底层模块绑定在一起，如果计算机中的主板采用这种原则，主板一坏，那么CPU、内存、显卡等那些全都要换，这种设计是不合理的。反过来，假如内存条或者CPU或者显卡等其中任一一个坏了，也不能造成其它零件不能使用的情况，所以，需要把高层模块和底层模块让它们都依赖于抽象，谁坏了，出了问题，可以直接更换，或者在这个基础上进行排查更改。

第二句话，可以这么理解：比如，我有一个主板，主板上面有冯诺依曼的五大部件，假设某一天内存条坏了需要更换，在这里更换的是内存条，而不是整个主板。主板上给内存条留有接口，而厂家必须照着这个接口生产内存条，而不是某个品牌自己专门开创一个自己的接口，这样的话，更换内存条时，需要把整个主板都换了。所以，这里的内存条内部设计(存储颗粒，电路设计等)都是内部封装好了的(细节)，而这个需要依赖内存条设计的金手指接口(抽象)，所以依赖倒转原则:抽象(内存条接口)不应该依赖细节(内存条内部封装)，而细节(内存条内部封装)应该依赖抽象(内存条接口)。

收音机是典型的过度耦合，收音机出故障，不懂的人没法修理，因为任何问题都依赖于其它部件，各个部件相互依赖，难以维护。

依赖倒转是面向对象设计的标志，程序中所有的依赖关系都是终止于抽象类或者接口。

---

四、里氏代换原则(LSP)

里氏代换原则(Liskov Substitution Principle ,LSP):

里氏替换原则是继承复用的基石，一个软件实体如果使用的是一个父类的话，那么一定使用于其子类，而且它还察觉不出父类对象和子类对象的区别，也就是说，把父类都替换成它的子类，程序的行为没有变化。子类型必须能够替换掉它们的父类型。

子类能够替换父类出现能够出现的任何地方，比如你能代表你爸去你姥姥家干活。

有点开闭原则的意思，子类可以扩展父类的功能，但是不能改变父类原有的功能。

---

五、接口分离原则(ISL)

接口隔离(分离)原则(Interface Segregation Principle，简称ISL):

一个类对另一个类的依赖应该建立在最小的接口上。

• 一个类不应该依赖他不需要的接口。每个接口不存在子类用不到却必须实现的方法，否则要将接口拆分。
• 接口的粒度要尽可能小，如果一个接口的方法过多，可以拆成多个接口。

使用多个专门的接口比使用单一的总接口要好，接口隔离原则是为了约束接口、降低类对接口的依赖性。

---

六、迪米特原则(LOD)

迪米特法则((Law of Demeter, 简称LoD):也叫最少知识原则

​ 如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个的方法，可以通过第三者转发这个调用。一个类尽量不要与其他类发生关系

• 一个类对其他类知道的越少，耦合越小。
• 当修改一个类时，其他类的影响就越小，发生错误的可能性就越小。

在类的结构设计上，每一个类都应当尽量降低成员的访问权限，最少知识原则，是强调了类之间的耦合。类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。

---

七、合成复用原则(CARP)

合成复用原则(Composite/Aggregate Reuse Principle，简称CARP):
尽量使用合成/聚合的方式，而不是使用继承。
当父类和子类作者是同一个人(类)时，继承随便用。当父类和子类作者不是同一个人时，优先考虑组合。当仅仅为了复用某个类的方法时，优先考虑组合，因为继承会带来一些不想要的方法。

---

七个原则总结：

开放封闭原则(OCP):对扩展开放，对修改关闭

单一职责原则(SRP):类要职责单一

依赖导致(DIP):面向接口编程

接口分离(ISL):设计接口要精简单一

迪米特原则(LOD):降低类之间的耦合

合成复用原则(CARP):使用合成/聚合，而不是继承。

设计模式要解决的问题就是:
找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起；
针对接口编程，而不是针对实现编程；
为了交互对象之间的松耦合设计而努力。