GOF23种设计模式(Design Pattern)总结
2012-08-14 16:32
423 查看
GOF23种设计模式(Design Pattern)总结
比较设计模式 | 常用程度 | 适用层次 | 引入时机 | 结构复杂度 |
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 | 一般 | 应用级 | 设计时 | 比较复杂 |
原则、变化与实现
设计模式 | 变化 | 实现 | 体现的原则 |
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
没有设计模式是万能的,沉迷于获得一个解决方案的话可能会导致项目结构复杂、代码可读性差、并且造成项目延期
宠辱不惊,闲看庭前花开花落;去留无意,漫随天外云卷云舒。
相关文章推荐
- GOF23种设计模式(Design Pattern)总结
- GOF23种设计模式(Design Pattern)总结
- GOF23种设计模式(Design Pattern)总结
- Gof的23种设计模式(Design pattern)
- 一句话总结GOF的23种设计模式 .
- 一句话总结GOF的23种设计模式
- 一句话总结GOF的23种设计模式
- 一句话总结GOF的23种设计模式
- 一句话总结GOF的23种设计模式
- 一句话总结GOF的23种设计模式
- 一句话总结GOF的23种设计模式
- Gof23种设计模式+简单工厂设计模式总结(二)
- Gof23种设计模式+简单工厂设计模式总结(一)
- Gof设计模式之对象结构模式总结
- 23种设计模式(GoF)(摘录)
- 23种设计模式总结
- GoF23种设计模式之行为型模式之迭代器模式
- GoF23种设计模式之创建型模式之抽象工厂模式
- GOF以及java的23种设计模式简介
- 非23种GOF设计模式之简单工厂模式