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

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）

定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。

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

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