设计模式六大原则
1，里氏替换原则：任何使用基类的地方，都可以透明的使用其子类。
2，依赖倒置原则：高层模块不应依赖低层模块，两者都应依赖其抽象，抽象不应依赖细节，细节应依赖抽象
3，迪米特法则：最少知识原则，一个对象应当对其他对象尽可能少的了解。
4，单一职责原则：一个类只负责一项职责。
5，开闭原则：类对扩展开放，对修改关闭。
6，接口隔离原则：类不应该依赖它不需要的接口，依赖关系应建立在最小的接口上。
设计模式按照其应用模式划分的类别
1，创建型
主要用于创建对象，为设计类实例化新对象提供指南
2，结构型
主要用于处理类或对象的组合，对类如何设计以形成更大的结构提供指南
3，行为型
主要用于描述类或对象的交互，以及职责的分配，对类之间交互，以及分配责任的方式提供指南
设计模式归类
1，创建型
工厂模式、抽象工厂模式、构造器模式、原型模式、单例模式
2，结构型
适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式、代理模式
3，行为型
责任链模式、命令模式、解释器模式、迭代器模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式、终结者模式
23种设计模式
1，工厂方法模式
定义一个用于创建对象（产品）的接口，由子类决定实例化哪个类的对象（产品）。
适用场景为当一个类不知道它所创建的产品的具体是哪个子类时，当创建的对象的过程希望延缓到子类中进行时，类希望子类指定它要创建的对象。
优点是没有了将应用程序类绑定到代码中的要求，代码只处理接口，因此可以使用任何实现了接口的类，允许子类提供对象的扩展版本，符合迪米特法则、依赖导致原则、里氏替换原则。
缺点是需要Creator和相应的子类作为工厂方法载体，如果应用模型确实需要creator和子类存在，则很好，否则，需要增加一个类层次。
应用举例为Windows的COM组件与MFC。
2，抽象工厂模式
提供创建一组或者一系列相关的或相互依赖对象的接口。
适用场景为系统独立于产品的创建、组成以及表示，系统配置成具有多个产品的系列，当要强调一系列相关的产品对象的设计以便于进行联合使用时，当提供一个产品类库，而只想要想显示它们的接口而不是实现。
优点为分离了具体类，更容易在产品系列中进行转换，提高了产品间一致性。
缺点是难以支持新的产品等级结构，支持新的产品等级结构需要扩展抽象工厂接口。
应用举例为在很多软件系统中需要更换界面主题，要求界面中的按钮、文本框、背景色等一起发生改变时，可以使用抽象工厂模式。
3，构建器模式
将复杂对象的构建与它的表示分离，使得同样的构建过程可以创造不同的表示。
适用场景为创建复杂对象的算法独立于组成对象的部分以及这些部分的集合方式，构造过程必须允许已构建对象有不同表示。
优点是产品的内部表象可以独立的变化，将构造代码与表示代码相分离，可以使客户端不必知道产品内部组成的细节。
缺点是构建器模式所常见的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用构建器模式。如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。
应用举例为在很多游戏软件中，地图包括天空、地面、背景等组成部分，任务角色包括人体、服装、装备等组成部分，可以使用建造者模式对其进行设计，通过不同的具体建造者创建不同类型的地图或人物。
4，原型模式
指定创建对象的种类，并通过拷贝这些原型创建新的对象。以一个已有的对象作为原型，通过它来创建新的对象。
适用场景为在运行时，指定需要实例化的类，例如动态载入，避免构建与产品的类层次结构相似的工厂类层次结构，当类的实例是仅有的一些不同状态组合。
优点是可以在运行时添加或删除产品，原型模式提供简化的创建结构，具有给一个应用软件加载新功能的能力，产品类不需要非得有任何实现确定的等级结构。
缺点是每一个类必须配备一个克隆方法。
5，单例模式
一个类只有一个实例
应用场景为只有一个实例
优点是对单个实例的受控制访问，名称空间减少，允许改进操作和表示，允许可变数目的实例，比类操作更灵活。
缺点是单例类的扩展有很大的困难，且职责过重，在一定程度上违背了单一职责原则。
应用举例为主键生成器。
6，适配器模式
将一个类的接口转换成客户希望的另一个接口，Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
适用场景为要使用已有的类，而该类接口与所需的接口并不匹配，要创建可重复的类，该类可以与不相干或未知类进行协助，即类之间不需要兼容接口，要在一个不同于已知对象接口的接口环境中使用对象，必须要进行多个源之间的接口转换的时候。
优点是允许两个或多个不兼容的对象进行交互和通信，提高已有功能的重复使用性增加了类的透明度，灵活性好
缺点是过多地使用适配器会让系统非常凌乱，不易整体进行把握。
应用举例为在.NET中有一个类库已经实现的、非常重要的适配器-dataAdapter。
7，桥接模式
将一个辅助的组件分成两个独立的但又相关的继承层次结构，功能性的抽象和内部实现。
适用场景为想避免在抽象及其实现之间存在永久的绑定，抽象以及其实现可以使用子类进行扩展，抽象的实现被改动应该对客户端没有影响。
优点是可以将接口与实现相分离，提高可扩展性，对客户端隐藏了实现的细节。
缺点是增加了系统的理解和设计难度，要求正确识别出系统中两个独立变化的维度，因此其中使用范围有一定的局限。
8，组合模式
将对象组合成树形结构以表示“部分-整体”的层次结构。
使用场景为想表示对象的部分-整体层次结构，希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象，结构可以具有任何级别的复杂性，而且是动态的。
优点是清楚的定义分层次的复杂对象，表示对象的全部或部分层次，使得增加新构建更容易，提高了结构的灵活性和可管理的接口。
缺点是使设计变得更加抽象，如果对象的业务规则很复杂，则实现组合模式具有很大的挑战性，而且不是所有的方法都与叶子对象子类有关联。
应用举例为部分、整体场景，如属性菜单，文件文件夹的管理。
9，装饰模式
动态的给对象添加一些额外的责任，就增加功能来说，装饰比生成子类更为灵活。
适用场景为想要在单个对象动态并且透明地添加责任，而这样不会影响其他对象，想要在以后可能要修改对象中添加责任，当无法通过静态子类化实现扩展时。
优点为比静态继承具有更大的灵活性，简化代码，改进对象扩展性，用户可以通过编写新的类来作出改变，装饰类和被装饰类可以独立发展，不会相互耦合。
缺点为多层装饰比较复杂。
10，外观模式
为子系统中的一组接口提供一个统一的接口，外观模式通过提供一个高层接口，隔离了外部系统与子系统间复杂交互过程，使得复杂系统的子系统更容易使用。
适用场景为为一个复杂子系统提供一个简单接口时，客户程序与抽象类的实现部分之间存在着很大的依赖性，构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点，如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通信，从而简化了它们之间的依赖关系。
优点是在不减少系统所提供的的选项的情况下，为复杂系统提供了简单的接口，对客户端屏蔽了子系统组件，提供了子系统与客户端之间的弱耦合度，将客户端请求转换后发送给能够处理这些请求的子系统。
缺点是不能很好地限制客户使用子系统类，如果客户访问子系统类做太多的限制，则减少了可变性和灵活性，在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或者客户端的源代码，违背了开闭原则。
11，享元模式
通过共享对象减少系统中低等级的、详细的对象数据
使用场景为应用程序使用大量的对象，由于对象数据巨大，导致很高的存储开销
优点是减少了要处理的对象数据，如果对象能够持续，可以减少内存和存储设备
缺点是使得应用程序在某种程度上来说更加复杂了，为了使对象可以共享，享元模式需要将相遇俺对象的状态外部化，而读取外部状态使得运行时间变长。
12，代理模式
为控制对初始对象的访问，提供了一个代理或者占位符对象
使用场景为当需要为一个对象在不同的地址空间提供局部的代表时当需要创建开销非常大的对象时。
优点是远程代理可以隐藏对象位于不同的地址空间的事实，虚拟代理可以执行优化操作。
缺点是请求的处理速度变慢，实现代理模式需要额外的工作，从而增加了系统实现的复杂度。
应用举例为防火墙代理，保护目标不让恶意用户靠近。
13，责任链模式
在系统中建立一个链，消息可以首先接收到它的级别被处理，或者定位到可以处理它的对象。
适用场景为多个对象可以处理一个请求，而其处理器却是未知的，可以动态指定能够处理请求的对象集。
优点是减低耦合度，增加向对象指定责任的灵活性。
14，命令模式
在对象中封装请求，保存命令并传递给方法以及像任何其他对象一样返回命令。
适用场景为想要通过执行的动作来参数化对象，在不同的时间指定、排序以及执行请求。
优点是添加新命令不用修改已有类，将操作对象与知道如何完成操作的对象相分离。
15，解释器模式
解释定义其语法表示的语言
适用场景为语言的语法比较简单，效率并不是最主要的问题
优点是容易修改并扩展语法，容易实现语法
16，迭代器模式
提供一种方法顺序的访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。
适用场景为在不开放集合对象内部表示的前提下，访问集合对象内容，支持集合对象的多重遍历，为遍历集合中的不同结构提供了统一的接口。
优点是支持结合的不同遍历，简化结合接口。
17，备忘录模式
保持对象状态的快照，在不向外界公开其内容的情况下返回到它的最初状态。
适用场景为必须保存对象的快照，使用直接接口来获取状态可能会公开对象的实现细节，从而破坏对象的封装性。
优点是保持封装完整性，简化了返回到初始状态所需的操作。
18，观察者模式
为组件向相关接受方广播消息提供了灵活的方法。
适用场景为对一个对象修改涉及其他对象的修改而不知道多少对象需进行修改，对象应该能够在不用假设对象标识的前提下通知其它对象。
优点是抽象了主体与Observer之间的耦合关系。
19，状态模式
允许对象在内部状态变化时变更其行为，并且修改其类。
适用场景为对象行为依赖其状态，且对象必须在运行时根据其状态修改行为，操作具有大量以及多部分组成的取决于对象状态的条件语句。
优点为定位指定状态的行为，并根据不同状态来划分行为。
20，策略模式
定义了一组用来表示可能行为集合的类
适用场景为许多相关类只是在行为方面有所区别，需要算法的不同变体，算法适用客户端位置的数据
优点为另一种子类化方法，在类自身中定义行为，减少条件语句，更容易扩展模型。
21，模板方法模式
提供了在不重写方法的前提下允许子类重载部分方法的方法
适用场景为想要一次实现算法的不变部分，适用子类实现算法的可变行为，子类间通用行为需要分解，定位到通用类，可以避免代码重复问题。
优点为代码使用
22，访问者模式
提供了一种方便的，可维护的方法来表示在对象解构元素上进行操作。该模式允许在不改变操作元素的类的前提下定义一个新的操作。
适用场景为定义对象结构的类很少被修改，但想要在此结构上定义新的操作，对象结构包含许多具有不同接口的对象类，并且想要对这些依赖于具体类的对象进行操作。
优点为容易添加新操作，集中相关操作并且排除不相关操作。
23，中介者模式
通过引入一个能够管理对象间消息分布的对象，简化了系统中对象的通信。
适用场景为对象集合需要以一个定义规范但复杂的方式进行通信，想要在不使用子类的情况下自定义分布在几个对象之间的行为。
优点是去除对象间的影响，简化对象间的协议，集中化了控制。