设计模式 —— 设计模式三大分类与六大原则

0. 前言

设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。

项目中合理的运用设计模式可以完美的解决很多问题,每种模式在现在中都有相应的原理来与之对应,每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的核心解决方案,这也是它能被广泛应用的原因。


0.1 UML图

统一建模语言(Unified Modeling Language,UML)

详见之前一篇文章UML类图


1. 设计模式的三大分类

共有23种设计模式,可以分为3类:

  • 创建型(Creational):
  • 结构型(Structural):
  • 行为型(Behavioral):

(1) 创建型(5种)

  • 工厂方法模式(Factory Method) 重要程度:5
  • 抽象工厂模式(Abstract Factory) 重要程度:5
  • 简单工厂模式(Simple Factory) 重要程度:4 (后来添加的)
  • 单例模式(Singleton) 重要程度:4
  • 原型模式(Prototype) 重要程度:3
  • 建造者模式(Builder) 重要程度:2
(2) 结构型(7种)
  • 外观模式(Facade) 重要程度:5
  • 适配器模式(Adapter) 重要程度:4
  • 组合模式(Composite) 重要程度:4
  • 代理模式(Proxy) 重要程度:4
  • 装饰模式(Decorator) 重要程度:3
  • 桥接模式(Bridge) 重要程度:3
  • 享元模式(Flyweight) 重要程度:1
(3) 行为型(11种)
  • 观察者模式(Observer) 重要程度:5
  • 迭代器模式(Iterator) 重要程度:5
  • 命令模式(Command) 重要程度:4
  • 策略模式(Stragety) 重要程度:4
  • 责任链模式(Chain of Responsibility) 重要程度:3
  • 状态模式(State) 重要程度:3
  • 模板方法模式(Template Method) 重要程度:3
  • 中介者模式(Mediator) 重要程度:2
  • 备忘录模式(Memento) 重要程度:2
  • 解释器模式(Interpreter) 重要程度:1
  • 访问者模式(Visitor) 重要程度:1
2. 设计模式的六大原则
(1) 单一职责原则(Single Responsibility Principle, SRP)
定义:就一个类而言,应该有且仅有一个引起它变化的原因。
简单来说:一个类中应该是一组相关性很高的函数、数据的封装。
好处:类的复杂度降低、可读性提高、可维护性提高、扩展性提高、降低了变化引起的风险。
需要注意:单一职责的划分界限并不总是那么清晰,如何划分一个类、一个函数的职责,需要根据个人经验、具体的业务逻辑而定。

(2) 里氏替换原则(Liskov Substitution Principle, LSP)

定义:所有引用基类的地方必须能透明地使用其子类的对象。

通俗地讲:只要父类能出现的地方子类就能出现,而且替换为子类也不会产生任何错误或异常。反之就不行了,有子类出现的地方,父类未必就能适应。

好处:增强程序的健壮性,即使增加了子类,原有的子类还可以继续运行。

需要注意:如果子类不能完整地实现父类的方法,或者父类的某些方法在子类中已经发生“畸变”,则建议断开父子继承关系 采用依赖、聚合、组合等关系代替继承。


(3) 依赖倒置原则(Dependence Inversion Principle, DIP)

定义:高层模块不应该依赖底层模块,两者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。

通俗地讲:模块间的依赖通过抽象产生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的。

好处:扩展性提高、解耦

需要注意:依赖倒置原则指代了一种特定的解耦形式,使得高层次的模块不依赖与低层次的模块的实现细节的目的。


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

定义:类之间的依赖关系应该建立在最小的接口上。

通俗地讲:建立单一接口,不要建立庞大臃肿的接口;尽量细化接口,接口中的方法尽量少。

也就是说,我们要为各个类建立专用的接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

需要注意:

  • 接口尽量小,但是要有限度。对接口进行细化可以提高程序设计灵活性,但是如果过小,则会造成接口数量过多,使设计复杂化,所以一定要适度。
  • 提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。
  • 为依赖接口的类定制服务。只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务,才能建立最小的依赖关系。

(5) 迪米特定律(Law of Demeter, LoD)

也称为最少知识原则(Least Knowledge Principle)

定义:一个对象应该对其他对象有最少的了解。

通俗地讲:一个类应该对自己依赖的类知道得越少越好。

自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚。

无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率。

低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的。


(6) 开闭原则(Open Close Principle, OCP)

定义:软件中的对象(类、模块、函数等)应该对于扩展是开放的,但是,对于修改是封闭的。

通俗地讲:在软件的生命周期内,变化(升级和维护等)一定会发生。当软件需要变化时,应该尽量通过扩展的方式来实现变化,而不是通过修改已有的代码来实现。

然而,在实际的开发过程中,修改原有代码、扩展代码往往是同时存在的。

你可能感兴趣的:(设计模式)