设计模式的目的
设计模式是为了更好的代码重用性，可读性，可靠性，可维护性。
设计模式的类型
- 创建型模式（Creational Patterns）
- 结构型模式（Structural Patterns）
- 行为型模式（Behavioral Patterns）
创建型模式
单例模式(Singleton Pattern): 保证一个类仅有一个实例，并提供一个访问它的全局访问点。例：跨窗体访问同一个实例。
工厂模式(Factory Pattern): 根据提供给工厂的数据，从一系列相关的类中选择一个类实例并返回。例:Oracle,SQL Server 访问类的选择
抽象工厂模式(Abstract Factory Pattern): 为一组类返回一个工厂。
生成器模式(Builder Pattern): 根据提供给他的数据及表示，组装成新的对象。 例：根据用户不同的选择显示不同控件。
原型模式(Prototype Pattern): 由结果到一个新的结果。例：根据由执行的SQL 查询结果得到另一个结果。与生成器类似工厂，两者都返回由许多方法的对象组成的类。差别:抽象工厂返回一系列相关的类。生成器是根据提供给它的数据一步一步地构建一个复杂的对象。
结构型模式
- 适配器模式(Adapter Pattern): 将一个类将一种接口转换成另一种接口。
- 桥接模式(Bridge Pattern): 类的接口和它的实现相分离，无需改变调用者的代码即可替代实现的过程。
- 组成模式(Composite Pattern): 组合就是对象的结合。可以构建部分-整体的关系或数据的树形关系。
- 装饰模式(Decorator Pattern): 用一个类包装给定的类改变单个对象的行为，但不需要创建一个新的派生类。
- 外观模式(Facde Pattern): 可以将一系统复杂的类包装成一个简单的封闭接口。
- 享元模式(Flyweight Pattern): 通过共享（把参数移动外部）大幅地减少单个实例的数目。
- 代理模式(Proxy Pattern): 为一个复杂的对象提供一个简单的占位对象。
行为型模式
中介者模式(Mediator Pattern):中介者做为唯一了解其它类的一个,简化了通信.促进类之音的松散便于修改维护。每个和中介者通信的控件都称为同事。 应用:可视界面的程序中，当面临多个对象之间复杂的通信时，可使用。
命令模式(Command Pattern):只将请求转发给特定的对象。目的：将程序的界面和操作分离。缺点：增加了散乱的小类
备忘录模式(Memento Pattern):保存对象的数据以便以后能够恢复它。 发起人(Originator):是一个对象，我们要保存它的状态。备忘录(Memento):是另外一个对象，它保存了发起人的状态。负责人(Caretaker):管理状态保存的时机，保存备忘录，并且如果需要的话，使用备忘录恢复发起人的状态。
状态模式(State Pattern):用一个对象表示程序的状态，并通过转换对象来转换程序的状态。以前,根据传进来的参数执行不同的计算或显示不同的内容。switch-case/if else状态模式要取代它。
策略模式(Stractegy Pattern):与状态模式相似,根据需要选择一封装在Context驱动器类。
观察者模式(Observer Pattern):以多种形式显示数据。在观察者模式中，把数据称为目标(Subject),把每种显示称为观察者(Observer)
解释器模式(Interpreter Pattern):为某种语言定义一个文法，并用该文法解释语言中的语句。 适用性: 1.当读者需要一个命令解释器分析用户命令时。 2.当程序需要分析一个代数串时。 3.发程序要生成各种形式的输出时。
迭代器模式(Iterator Pattern):允许使用一个标准的接口顺序访问一个数据列表或集合。
模板方法模式（Template Method Pattern):先创建一个父类，把其中一个或多个方法留个子类实现。是一种非常简单又常用的模式。思想：将一个类的基本部分抽取出来放到一个基类中，不必重出现在一个派生类中。
职责链(Chain of Responsibility):允许多个类处理同一个请求。 要点： 1.链的组织是从最特珠的到最一般的。 2.不能保证在任何情况下都会有响应。 职责链用于分析器与编译器。
空对象模式（Null Object Pattern）
设计模式的六大原则
单一职责原则(Single Responsibility Principle, SRP)：
一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
单一职责原则告诉我们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。
单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。
开闭原则（Open Close Principle, OCP）
开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，抽象化是开闭原则的关键。
里氏代换原则（Liskov Substitution Principle, LSP）
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
依赖倒转原则（Dependence Inversion Principle, DIP）
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
接口隔离原则（Interface Segregation Principle, ISP）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
迪米特法则，又称最少知道原则(Law of Demeter, LoD）
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立, 迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。