步步为营 .NET 设计模式学习笔记系列总结
设计模式我从开篇到23种设计模式的讲解总共花了进两个月的时间,其间有很多读者给我提出了很好的建议,同时也指出了我的不足,对此我表示感谢,正是由于很多读者的支持我才能坚持的写到最后.在此表示我真诚的谢意.
系列导航
步步为营 .NET 设计模式学习笔记 一、开篇（设计模式之泡妞二十三招）
步步为营 .NET 设计模式学习笔记 二、Abstract Factory(抽象工厂)
步步为营 .NET 设计模式学习笔记 三、Strategy(策略模式)
步步为营 .NET 设计模式学习笔记 四、Singleton(单例模式)
步步为营 .NET 设计模式学习笔记 五、Prototype(原型模式)
步步为营 .NET 设计模式学习笔记 六、Adapter(适配器模式)
步步为营 .NET 设计模式学习笔记 七、Proxy(代理模式)
步步为营 .NET 设计模式学习笔记 八、State(状态模式)
步步为营 .NET 设计模式学习笔记 九、Command(命令模式)
步步为营 .NET 设计模式学习笔记 十、Builder(建造者模式)
步步为营 .NET 设计模式学习笔记 十一、Iterator(迭代器模式)
步步为营 .NET 设计模式学习笔记 十二、Observer (观察者模式)
步步为营 .NET 设计模式学习笔记 十三、Bridge (桥接模式)
步步为营 .NET 设计模式学习笔记 十四、Decorator(装饰模式)
步步为营 .NET 设计模式学习笔记 十五、Composite(组合模式)
步步为营 .NET 设计模式学习笔记 十六、Facade(外观模式)
步步为营 .NET 设计模式学习笔记 十七、Flyweight(享元模式)
步步为营 .NET 设计模式学习笔记 十八、Template(模板模式)
步步为营 .NET 设计模式学习笔记 十九、Chain of Responsibility(职责链模式)
步步为营 .NET 设计模式学习笔记 二十、Mediator(中介者模式)
步步为营 .NET 设计模式学习笔记 二十一、Visitor(访问者模式)
步步为营 .NET 设计模式学习笔记 二十二、Memento(备望录模式)
步步为营 .NET 设计模式学习笔记 二十三、Interpreter(解释器模式)
步步为营 .NET 设计模式学习笔记 二十四、Factory Method(工厂方法模式)
设计模式原则
使用设计模式的根本原因是适用变化，提高代码复用率，使软件更具有可维护性和可扩展性。需要遵循以下几个原则：单一职责原色、开放封闭原则(Open Closed Principal)、依赖倒置原则、里氏代换原则。
1.单一职责原则
就一个类而言，应该只有一个引起他变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破会。
2.开放封闭原则
软件实体（类、模块、函数等）应该可以扩展，但不可以修改。也就是说对扩展是开放的，对修改是封闭的。一般来说，面对需求，对程序的改动是通过添加新代码进行的，而不是更改现有代码。
3.依赖倒置原则
抽象不应该以来细节，细节应该依赖抽象，也就是提倡的“面对接口编程，而不是面对实现编程”。也可以这样理解：高层模块不应该依赖底层模块，两个都应该抽象；抽象不应该依赖细节，细节应该依赖抽象。
4.里氏代换原则
子类必须能够替换掉他们的父类型。也就是说，在软件开发过程中，子类替换掉父类，程序的功能行为没有变化。只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也可以在父类的基础上增加新的行为。
三种设计模型
创建型模式
1.Singleton模式解决的是实体对象个数的问题。除了Singleton之外，其他创建型模式解决的都是new所带来的耦合关系。
2.Factory Method、Abstract Factory、Builder都需要一个额外的工厂类来负责实例化“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。
3.如果遇到“易变类”，起初的设计是从FactoryMethod开始，当遇到更多的复杂变化时，再考虑重构为其他三种工厂模式（Abstract Factory,Builder ， Prototype ）。
结构型模式
1.Adapter模式注重转换接口，将不吻合的接口适配对接
2.Bridge模式注重分离接口与其实现，支持多维度变化
3.Composite模式注重统一接口，将“一对多”的关系转化为“一对一”的关系
4.Decorator模式注重稳定接口，在此前提下为对象扩展功能
5.Facade模式注重简化接口，简化组件系统与外部客户程序的依赖关系
6.Flyweight 模式注重保留接口，在内部使用共享技术对对象存储进行优化
7.Proxy 模式注重假借接口，增加间接层来实现灵活控制
行为型模式
1.Template Method模式封装算法结构，支持算法子步骤变化
2.Strategy模式注重封装算法，支持算法的变化
3.State模式注重封装与状态相关的行为，支持状态的变化
4.Memento模式注重封装对象状态变化，支持状态保存/恢复
5.Mediator模式注重封装对象间的交互，支持对象交互的变化
6.Chain Of Responsibility模式注重封装对象责任，支持责任的变化
7.Command模式注重将请求封装为对象，支持请求的变化
8.Iterator 模式注重封装集合对象内部结构，支持集合的变化
9.Interpreter模式注重封装特定领域变化，支持领域问题的频繁变化
10.Observer模式注重封装对象通知，支持通信对象的变化
11.Visitor模式注重封装对象操作变化，支持在运行时为类层次结构动态添加新的操作。
设计模式应用总结：
1.设计模式建立在对象对系统变化点的基础上进行，哪里有变化点，哪里应用设计模式。
2.设计模式应该以演化的方式来获得，系统的变化点往往是经过不断演化才能精确定位。
3.不能为了模式而模式，设计模式是一种软件设计的软力量，而非规标准，不应夸大设计模式的作用。
各种模式比较
|
设计模式 |
常用程度 |
适用层次 |
引入时机 |
结构复杂度 |
|
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 |
对象操作变化 |
封装对象操作变化 |
开闭原则 |
到这里,设计模式系系就介绍完了,由于我的水平有限,存在失误和不足,欢迎拍砖.
感谢spring yang
，在这转载了。。。
