设计模式的原则？
l 单一职责：你不希望因为电脑内存损坏而更换CPU吧，同样也不应该让一个类有多种修改的理由。
l 对扩展开放，对修改封闭：你一定不希望电脑只有一个内存槽，加内存就要换主板吧，程序也应该能在不修改原先程序的情况下就能扩展功能。
l 里氏替换：如果你买的DX9显卡不支持DX9特性，那么这个显卡一定没法用。如果父类的方法在子类中没有实现那就晕了。在程序的世界中千万别认为鸟都会飞，先考虑清楚将会有哪些鸟吧。
l 依赖倒置：针对接口编程，这样即使实现有变也不需要修改外部代码。其实，现在电脑的硬件、网络通讯等都是符合这个原则的，比如USB接口、PCI-E接口、TCP/IP协议。
l 接口隔离：花3000买一个带拍照、听MP3功能的手机还是花1000买一个手机、1000买一个MP3、1000买一个数码相机呢？买了前者的话手机动不动就要修，而且还不一定是因为不能打电话而修，买了后面三样的话即使修也不影响其它使用，你说买哪个？
记得看过一个例子很恰当，说是修电脑比修收音机简单多了。电脑坏了，更换一个零件即可，原因是电脑中的各部分都是基于相对稳定的接口，而且部件各司其职，不会相互影响，电脑本身就是一个非常符合设计原则的产品。收音机的修理没有这么简单了，没有什么部件是插件式的，会修收音机的人肯定明白其中每一个部件的原理。
小程序就好像收音机，确实可以这么做，一共才一个人做的，即使重新做也用不了多少时间。几十个人的大项目如果要改一个需求需要牵涉所有人来修改，那么这个项目用不了多少时间就会因为维护成本太大，维护后BUG太多而报废。
比较
设计模式 |
常用程度 |
适用层次 |
引入时机 |
结构复杂度 |
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 没有设计模式是万能的，沉迷于获得一个解决方案的话可能会导致项目结构复杂、代码可读性差、并且造成项目延期
结束语
l 常用的GOF 23种设计模式介绍完了，这才是起点。
l 本系列文章并没有结束，关注之后非GOF 23种设计模式的相关文章。
l 如果适当运用C# 2.0一些有用的特性（特别是代理、泛型以及分部类和设计模式关联比较大）的话，传统的设计模式有非常大的改进的余地。在实际运用的过程中，优先考虑适用语言特性，如果不行再去考虑适用设计模式。
l 迭代器模式（在C# 2.0中实现非常简单）、解释器模式（应用面非常小，自己也没有整明白）以及备忘录模式（比较简单，没有什么可说的）没有单独立文介绍，但在代码包中包含了相应的例子，所有代码点击这里下载。