简介
世界上本没有路，走的人多了也就成了路；世界上本来没有设计模式。用的人多了，也就成了设计模式。所以，我们不是严格按照它的定义去执行，可以根据自己的实际场景、需求去变通。领悟了其中的思想，实现属于自己的设计模式。通过对设计模式理解，让它它慢慢地影响你写代码的思维方式；
我们为什么要使用设计模式？使用设计模式是为了可重用代码，让代码容易被他人理解、保证代码可靠性以及可维护性。
最近看了一些关于设计模式的文章，以前也实际用过一些，这里希望将设计模式系列做一下总结，帮助我更深入地理解设计模式；
设计模式导航
创建型
C#设计模式(2)——简单工厂模式
C#设计模式(3)——工厂方法模式
C#设计模式(4)——抽象工厂模式
C#设计模式(5)——建造者模式（Builder Pattern）
C#设计模式(6)——原型模式（Prototype Pattern）
结构型
C#设计模式(7)——适配器模式（Adapter Pattern）
C#设计模式(8)——桥接模式（Bridge Pattern）
C#设计模式(9)——装饰者模式（Decorator Pattern）
C#设计模式(10)——组合模式（Composite Pattern）
C#设计模式(11)——外观模式（Facade Pattern）
C#设计模式(12)——享元模式（Flyweight Pattern）
C#设计模式(13)——代理模式（Proxy Pattern）
行为型
C#设计模式(14)——模板方法模式（Template Method）
C#设计模式(15)——命令模式（Command Pattern）
C#设计模式(16)——迭代器模式（Iterator Pattern）
C#设计模式(17)——观察者模式（Observer Pattern）
C#设计模式(18)——中介者模式（Mediator Pattern）
C#设计模式(19)——状态者模式（State Pattern）
C#设计模式(20)——策略者模式（Stragety Pattern）
C#设计模式(21)——责任链模式
C#设计模式(22)——访问者模式（Vistor Pattern）
C#设计模式(23)——备忘录模式（Memento Pattern）
设计模式分类
创建型模式
创建型模式就是用来创建对象的模式，抽象了实例化的过程。所有的创建型模式都有两个共同点。第一，它们都将系统使用哪些具体类的信息封装起来；第二，它们隐藏了这些类的实例是如何被创建和组织的。创建型模式包括单例模式、工厂方法模式、抽象工厂模式、建造者模式和原型模式。
- 单例模式：解决的是实例化对象的个数的问题，比如抽象工厂中的工厂、对象池等，除了Singleton之外，其他创建型模式解决的都是 new 所带来的耦合关系。
- 抽象工厂：创建一系列相互依赖对象，并能在运行时改变系列。
- 工厂方法：创建单个对象，在Abstract Factory有使用到。
- 原型模式：通过拷贝原型来创建新的对象。
工厂方法，抽象工厂, 建造者都需要一个额外的工厂类来负责实例化“一个对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。
结构型模式
结构型模式，顾名思义讨论的是类和对象的结构 ，主要用来处理类或对象的组合。它包括两种类型，一是类结构型模式，指的是采用继承机制来组合接口或实现；二是对象结构型模式，指的是通过组合对象的方式来实现新的功能。它包括适配器模式、桥接模式、装饰者模式、组合模式、外观模式、享元模式和代理模式。
- 适配器模式注重转换接口，将不吻合的接口适配对接
- 桥接模式注重分离接口与其实现，支持多维度变化
- 组合模式注重统一接口，将“一对多”的关系转化为“一对一”的关系
- 装饰者模式注重稳定接口，在此前提下为对象扩展功能
- 外观模式注重简化接口，简化组件系统与外部客户程序的依赖关系
- 享元模式注重保留接口，在内部使用共享技术对对象存储进行优化
- 代理模式注重假借接口，增加间接层来实现灵活控制
行为型模式
行为型模式是对在不同对象之间划分责任和算法的抽象化。行为模式不仅仅关于类和对象，还关于它们之间的相互作用。行为型模式又分为类的行为模式和对象的行为模式两种。
- 类的行为模式——使用继承关系在几个类之间分配行为。
- 对象的行为模式——使用对象聚合的方式来分配行为。
行为型模式包括11种模式：模板方法模式、命令模式、迭代器模式、观察者模式、中介者模式、状态模式、策略模式、责任链模式、访问者模式、解释器模式和备忘录模式。
- 模板方法模式：封装算法结构，定义算法骨架，支持算法子步骤变化。
- 命令模式：注重将请求封装为对象，支持请求的变化，通过将一组行为抽象为对象，实现行为请求者和行为实现者之间的解耦。
- 迭代器模式：注重封装特定领域变化，支持集合的变化，屏蔽集合对象内部复杂结构，提供客户程序对它的透明遍历。
- 观察者模式：注重封装对象通知，支持通信对象的变化，实现对象状态改变，通知依赖它的对象并更新。
- 中介者模式：注重封装对象间的交互，通过封装一系列对象之间的复杂交互，使他们不需要显式相互引用，实现解耦。
- 状态模式：注重封装与状态相关的行为，支持状态的变化，通过封装对象状态，从而在其内部状态改变时改变它的行为。
- 策略模式：注重封装算法，支持算法的变化，通过封装一系列算法，从而可以随时独立于客户替换算法。
- 责任链模式：注重封装对象责任，支持责任的变化，通过动态构建职责链，实现事务处理。
- 访问者模式：注重封装对象操作变化，支持在运行时为类结构添加新的操作，在类层次结构中，在不改变各类的前提下定义作用于这些类实例的新的操作。
- 备忘录模式：注重封装对象状态变化，支持状态保存、恢复。
- 解释器模式：注重封装特定领域变化，支持领域问题的频繁变化，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。
设计原则
使用设计模式的根本原因是适应变化，提高代码复用率，使软件更具有可维护性和可扩展性。并且，在进行设计的时候，也需要遵循以下几个原则：单一职责原则、开放封闭原则、里氏代替原则、依赖倒置原则、接口隔离原则、合成复用原则和迪米特法则。下面就分别介绍了每种设计原则。
单一职责原则
就一个类而言，应该只有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会影响到其他的职责，另外，把多个职责耦合在一起，也会影响复用性。
开闭原则(Open-Closed Principle)
开闭原则即OCP（Open-Closed Principle缩写）原则，该原则强调的是：一个软件实体（指的类、函数、模块等）应该对扩展开放，对修改关闭。即每次发生变化时，要通过添加新的代码来增强现有类型的行为，而不是修改原有的代码。
里氏代替原则(Liskov Substitution Principle)
Liskov Substitution Principle,LSP（里氏代替原则）指的是子类必须替换掉它们的父类型。也就是说，在软件开发过程中，子类替换父类后，程序的行为是一样的。只有当子类替换掉父类后，此时软件的功能不受影响时，父类才能真正地被复用，而子类也可以在父类的基础上添加新的行为。
依赖倒置原则
依赖倒置（Dependence Inversion Principle, DIP）原则指的是抽象不应该依赖于细节，细节应该依赖于抽象，也就是提出的 “面向接口编程，而不是面向实现编程”。这样可以降低客户与具体实现的耦合。
接口隔离原则
接口隔离原则（Interface Segregation Principle, ISP）指的是使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责，而应把每个职责分离到多个专门的接口中，进行接口分离。过于臃肿的接口是对接口的一种污染。
合成复用原则
合成复用原则（Composite Reuse Principle, CRP）就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已用功能的目的。简单地说，就是要尽量使用合成/聚合，尽量不要使用继承。
要使用好合成复用原则，首先需要区分"Has—A"和“Is—A”的关系。
“Is—A”是指一个类是另一个类的“一种”，是属于的关系，而“Has—A”则不同，它表示某一个角色具有某一项责任。导致错误的使用继承而不是聚合的常见的原因是错误地把“Has—A”当成“Is—A”.
迪米特法则
迪米特法则（Law of Demeter，LoD）又叫最少知识原则（Least Knowledge Principle，LKP），指的是一个对象应当对其他对象有尽可能少的了解。也就是说，一个模块或对象应尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立，这样当一个模块修改时，影响的模块就会越少，扩展起来更加容易。
关于迪米特法则其他的一些表述有：只与你直接的朋友们通信；不要跟“陌生人”说话。
外观模式（Facade Pattern)和中介者模式（Mediator Pattern）就使用了迪米特法则。
参考：
http://www.cnblogs.com/mjq5150/p/6273341.html