比较
|
设计模式 |
常用程度 |
适用层次 |
引入时机 |
结构复杂度 |
|
Abstract Factory |
比较常用 |
应用级 |
设计时 |
比较复杂 |
|
Builder |
一般 |
代码级 |
编码时 |
一般 |
|
Factory Method |
很常用 |
代码级 |
编码时 |
简单 |
|
Prototype |
不太常用 |
应用级 |
编码时、重构时 |
比较简单 |
|
Singleton |
很常用 |
代码级、应用级 |
设计时、编码时 |
简单 |
|
Adapter |
一般 |
代码级 |
重构时 |
一般 |
|
Bridge |
一般 |
代码级 |
设计时、编码时 |
一般 |
|
Composite |
比较常用 |
代码级 |
编码时、重构时 |
比较复杂 |
|
Decorator |
一般 |
代码级 |
重构时 |
比较复杂 |
|
Facade |
很常用 |
应用级、构架级 |
设计时、编码时 |
简单 |
|
Flyweight |
不太常用 |
代码级、应用级 |
设计时 |
一般 |
|
Proxy |
比较常用 |
应用级、构架级 |
设计时、编码时 |
简单 |
|
Chain of Resp. |
不太常用 |
应用级、构架级 |
设计时、编码时 |
比较复杂 |
|
Command |
比较常用 |
应用级 |
设计时、编码时 |
比较简单 |
|
Interpreter |
不太常用 |
应用级 |
设计时 |
比较复杂 |
|
Iterator |
一般 |
代码级、应用级 |
编码时、重构时 |
比较简单 |
|
Mediator |
一般 |
应用级、构架级 |
编码时、重构时 |
一般 |
|
Memento |
一般 |
代码级 |
编码时 |
比较简单 |
|
Observer |
比较常用 |
应用级、构架级 |
设计时、编码时 |
比较简单 |
|
State |
一般 |
应用级 |
设计时、编码时 |
一般 |
|
Strategy |
比较常用 |
应用级 |
设计时 |
一般 |
|
Template Method |
很常用 |
代码级 |
编码时、重构时 |
简单 |
|
Visitor |
一般 |
应用级 |
设计时 |
比较复杂 |
注：常用程度、适用层次、使用时机等基于自己的理解，结构复杂度基于C#语言，表格中所有内容仅供参考。
原则、变化与实现
|
设计模式 |
变化 |
实现 |
体现的原则 |
|
Abstract Factory |
产品家族的扩展 |
封装产品族系列内容的创建 |
开闭原则 |
|
Builder |
对象组建的变化 |
封装对象的组建过程 |
开闭原则 |
|
Factory Method |
子类的实例化 |
对象的创建工作延迟到子类 |
开闭原则 |
|
Prototype |
实例化的类 |
封装对原型的拷贝 |
依赖倒置原则 |
|
Singleton |
唯一实例 |
封装对象产生的个数 |
|
|
Adapter |
对象接口的变化 |
接口的转换 |
|
|
Bridge |
对象的多维度变化 |
分离接口以及实现 |
开闭原则 |
|
Composite |
复杂对象接口的统一 |
统一复杂对象的接口 |
里氏代换原则 |
|
Decorator |
对象的组合职责 |
在稳定接口上扩展 |
开闭原则 |
|
Facade |
子系统的高层接口 |
封装子系统 |
开闭原则 |
|
Flyweight |
系统开销的优化 |
封装对象的获取 |
|
|
Proxy |
对象访问的变化 |
封装对象的访问过程 |
里氏代换原则 |
|
Chain of Resp. |
对象的请求过程 |
封装对象的责任范围 |
|
|
Command |
请求的变化 |
封装行为对对象 |
开闭原则 |
|
Interpreter |
领域问题的变化 |
封装特定领域的变化 |
|
|
Iterator |
对象内部集合的变化 |
封装对象内部集合的使用 |
单一职责原则 |
|
Mediator |
对象交互的变化 |
封装对象间的交互 |
开闭原则 |
|
Memento |
状态的辅助保存 |
封装对象状态的变化 |
接口隔离原则 |
|
Observer |
通讯对象的变化 |
封装对象通知 |
开闭原则 |
|
State |
对象状态的变化 |
封装与状态相关的行为 |
单一职责原则 |
|
Strategy |
算法的变化 |
封装算法 |
里氏代换原则 |
|
Template Method |
算法子步骤的变化 |
封装算法结构 |
依赖倒置原则 |
|
Visitor |
对象操作变化 |
封装对象操作变化 |
开闭原则 |
学习
l 掌握设计模式的意图以及解决的问题
l 掌握设计模式所封装的变化点以及优缺点
l 了解设计模式的结构图以及各角色的职责
l 项目中是否应用了设计模式不重要，重要的是设计模式是否正确应用
l 项目中应用的设计模式和GOF设计模式的结构是否一致不重要，重要的是是否从这个结构中得意
l 不管用了还是没有用设计模式，如果违背了原则，就是不恰当的设计
l 没有设计模式是万能的，沉迷于获得一个解决方案的话可能会导致项目结构复杂、代码可读性差、并且造成项目延期
来源：https://www.cnblogs.com/Jackey_Chen/archive/2008/11/17/1335319.html