首页 > 技术文章 > 设计模式-23种模式、设计原则

Jaysonhome 2020-08-31 10:24 原文

二、设计模式的六大原则(SOLID)

口诀 SOLID CD

想要达到这样的效果,我们需要使用接口和抽象类等。

1、单一职责原则(Single Responsibility Principle)

一个类应该只有一个发生变化的原因。
不要存在多于一个导致类变更的原因,也就是说每个类应该实现单一的职责,否则就应该把类拆分。

2、开闭原则(Open Closed Principle)

一个软件实体,如类、模块和函数应该对扩展开放,对修改关闭。
在程序需要进行拓展的时候,不能去修改原有的代码,而是要扩展原有代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。

3、里氏替换原则(Liskov Substitution Principle)

所有引用基类的地方必须能透明地使用其子类的对象。
任何基类可以出现的地方,子类一定可以出现。里氏替换原则是继承复用的基石,只有当衍生类可以替换基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。

里氏代换原则是对“开-闭”原则的补充。实现“开闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以里氏替换原则是对实现抽象化的具体步骤的规范。里氏替换原则中,子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构,通过这个规范的接口与外界交互,子类不应该随便破坏它。

4、接口隔离原则(Interface Segregation Principle)

  • 1、客户端不应该依赖它不需要的接口。
  • 2、类间的依赖关系应该建立在最小的接口上。
    每个接口中不存在子类用不到却必须实现的方法,如果不然,就要将接口拆分。使用多个隔离的接口,比使用单个接口(多个接口方法集合到一个的接口)要好。

5、依赖倒置原则(Dependence Inversion Principle)

  • 1、上层模块不应该依赖底层模块,它们都应该依赖于抽象。
  • 2、抽象不应该依赖于细节,细节应该依赖于抽象。
    面向接口编程,依赖于抽象而不依赖于具体。写代码时用到具体类时,不与具体类交互,而与具体类的上层接口交互。

6、组合原则(Composite Reuse Principle)

  • 尽量使用对象组合/聚合,而不是继承关系达到软件复用的目的。
    记忆口诀:SOLID CD(稳固的CD)。

7、迪米特法则(最少知道原则)(Principle of Least Knowledge,亦Law of Demeter)

  • 只与你的直接朋友交谈,不跟“陌生人”说话。
    一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂,都应该将逻辑封装在方法的内部,通过public方法提供给外部。这样当被依赖的类变化时,才能最小的影响该类。

最少知道原则的另一个表达方式是:只与直接的朋友通信。类之间只要有耦合关系,就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。

三、设计模式的三大类

创建型模式(Creational Pattern):对类的实例化过程进行了抽象,能够将软件模块中对象的创建和对象的使用分离。

(5种)工厂模式、抽象工厂模式、单例模式、建造者模式、原型模式

记忆口诀:创工原单建抽(原工厂单建创公园)
结构型模式(Structural Pattern):关注于对象的组成以及对象之间的依赖关系,描述如何将类或者对象结合在一起形成更大的结构,就像搭积木,可以通过简单积木的组合形成复杂的、功能更为强大的结构。

(7种)适配器模式、装饰者模式、代理模式、外观模式、桥接模式、组合模式、享元模式

记忆口诀:结享外组适代装桥(姐想外租,世代装桥)
行为型模式(Behavioral Pattern):关注于对象的行为问题,是对在不同的对象之间划分责任和算法的抽象化;不仅仅关注类和对象的结构,而且重点关注它们之间的相互作用。

(11种)策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式

记忆口诀:行状责中模访解备观策命迭(形状折中模仿,戒备观测鸣笛)

参考:
快速记忆23种设计模式
https://zhuanlan.zhihu.com/p/58903776

推荐阅读