无废话C#设计模式之二十二:总结(针对GOF23)
2010-05-12 00:33
281 查看
比较
注:常用程度、适用层次、使用时机等基于自己的理解,结构复杂度基于C#语言,表格中所有内容仅供参考。
原则、变化与实现
学习
l 掌握设计模式的意图以及解决的问题
l 掌握设计模式所封装的变化点以及优缺点
l 了解设计模式的结构图以及各角色的职责
l 项目中是否应用了设计模式不重要,重要的是设计模式是否正确应用
l 项目中应用的设计模式和GOF设计模式的结构是否一致不重要,重要的是是否从这个结构中得意
l 不管用了还是没有用设计模式,如果违背了原则,就是不恰当的设计
l 没有设计模式是万能的,沉迷于获得一个解决方案的话可能会导致项目结构复杂、代码可读性差、并且造成项目延期
结束语
l 常用的GOF 23种设计模式介绍完了,这才是起点。
l 本系列文章并没有结束,关注之后非GOF 23种设计模式的相关文章。
l 如果适当运用C# 2.0一些有用的特性(特别是代理、泛型以及分部类和设计模式关联比较大)的话,传统的设计模式有非常大的改进的余地。在实际运用的过程中,优先考虑适用语言特性,如果不行再去考虑适用设计模式。
l 迭代器模式(在C# 2.0中实现非常简单)、解释器模式(应用面非常小,自己也没有整明白)以及备忘录模式(比较简单,没有什么可说的)没有单独立文介绍,但在代码包中包含了相应的例子,所有代码点击这里下载。
设计模式 | 常用程度 | 适用层次 | 引入时机 | 结构复杂度 |
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 没有设计模式是万能的,沉迷于获得一个解决方案的话可能会导致项目结构复杂、代码可读性差、并且造成项目延期
结束语
l 常用的GOF 23种设计模式介绍完了,这才是起点。
l 本系列文章并没有结束,关注之后非GOF 23种设计模式的相关文章。
l 如果适当运用C# 2.0一些有用的特性(特别是代理、泛型以及分部类和设计模式关联比较大)的话,传统的设计模式有非常大的改进的余地。在实际运用的过程中,优先考虑适用语言特性,如果不行再去考虑适用设计模式。
l 迭代器模式(在C# 2.0中实现非常简单)、解释器模式(应用面非常小,自己也没有整明白)以及备忘录模式(比较简单,没有什么可说的)没有单独立文介绍,但在代码包中包含了相应的例子,所有代码点击这里下载。
相关文章推荐
- 无废话C#设计模式之二十二:总结(针对GOF23)
- (原创)无废话C#设计模式之二十二:总结(针对GOF23)
- 无废话C#设计模式之二十二:总结(针对GOF23)
- 无废话C#设计模式之二十二:总结
- c#设计模式-总结(针对GOF23)
- 针对架构设计的几个痛点,我总结出的架构原则和模式
- 针对架构设计的几个痛点,我总结出的架构原则和模式
- arm驱动程序——按键程序4_poll(韦东山的视频总结及针对linux-2.6.30)
- arm驱动程序——按键程序6_互斥1—原子操作(韦东山的视频总结及针对linux-2.6.30)
- 无废话C#设计模式之十一:Composite
- linux环境指令总结(针对服务器环境部署的指令)
- 无废话C#设计模式之十七:Chain Of Resp
- 针对复杂度总结
- C#设计模式总结
- 针对代码类测试的要点总结
- 【java基础知识总结】-特别针对零基础学习JAVA的初学者
- 废话总结
- 总结一些更多的针对webkit的HTML, CSS和Javascript方面的特性.
- 12-13号(针对没有回答清楚的)面试总结
- 无废话C#设计模式[002]