2013-03-01
首先声明,该系列文章基本上是从别人那面拷贝过来(见参考),我只是稍微整理了一下来理顺思路,也方便以后参考。
设计模式:抽象工厂模式(Abstract Factory)
设计模式:原型模式(Protype Pattern)
设计模式:创建型模式专题总结
设计模式:享元模式(Flyweight Pattern)
设计模式:中介者模式(Mediator Pattern)
设计模式:备忘录模式(Memento Pattern)
设计模式:解释器模式(Interpreter Pattern)
设计模式:职责链模式(Chain of Responsibility)
设计模式:访问者模式(Visitor Pattern)
设计模式:行为型模式专题总结
Singleton模式解决的是实体对象个数的问题。除了Singleton之外,其他创建型模式解决的都是new所带来的耦合关系。
Factory Method,Abstract Factory,Builder都需要一个额外的工厂类来负责实例化“易变对象”,而Prototype则是通过原型(一个特殊的工厂类)来克隆“易变对象”。
如果遇到“易变类”,起初的设计通常从Factory Method开始,当遇到更多的复杂变化时,再考虑重构为其他三种工厂模式(Abstract Factory,Builder,Prototype)。
Adapter模式注重转换接口,将不吻合的接口适配对接(适合于旧系统)
Bridge模式注重分离接口与其实现,支持多维度变化
Composite模式注重统一接口,将“一对多”的关系转化为“一对一”的关系
Decorator模式注重稳定接口,在此前提下为对象扩展功能
Facade模式注重简化接口,简化组件系统与外部客户程序的依赖关系
Flyweight模式注重保留接口,在内部使用共享技术对对象存储进行优化
Proxy模式注重假借接口,增加间接层来实现灵活控制
Template Method模式封装算法结构,支持算法子步骤变化
Strategy模式注重封装算法,支持算法的变化
State模式注重封装与状态相关的行为,支持状态的变化
Memento模式注重封装对象状态变化,支持状态保存/恢复
Mediator模式注重封装对象间的交互,支持对象交互的变化
Chain Of Responsibility模式注重封装对象责任,支持责任的变化
Command模式注重将请求封装为对象,支持请求的变化
Iterator模式注重封装集合对象内部结构,支持集合的变化
Interpreter模式注重封装特定领域变化,支持领域问题的频繁变化
Observer模式注重封装对象通知,支持通信对象的变化
Visitor模式注重封装对象操作变化,支持在运行时为类层次结构动态添加新的操作
【1】 TerryLee 的 .NET设计模式系列文章: http://www.cnblogs.com/Terrylee/archive/2006/07/17/334911.html
【2】 吕震宇 的 设计模式:http://www.cnblogs.com/zhenyulu/category/6930.html?Show=All
【3】 Wang Juqiang 的设计模式:http://www.cnblogs.com/wangjq/category/389973.html
【4】山天大畜 的设计模式:http://www.cnblogs.com/cdts_change/archive/2010/09/09/1822665.html
【5】duran1986 的 UML中关系图解: http://blog.csdn.net/duran1986/article/details/5573415