一、设计模式的分类
总体来说设计模式分为三大类：
创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、多例模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
创建型模式
抽象工厂模式(Abstract factory pattern): 提供一个接口，用于创建相关或依赖对象的家族，而不需要指定具体类。
生成器模式(Builder pattern): 使用生成器模式封装一个产品的构造过程，并允许按步骤构造。将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
工厂模式(factory method pattern): 定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个，工厂方法让类把实例化推迟到子类。
原型模式(prototype pattern): 当创建给定类的实例过程很昂贵或很复杂时，就使用原形模式。使用深拷贝或浅拷贝。
单例了模式(Singleton pattern): 确保一个类只有一个实例，并提供全局访问点。
多例模式(Multition pattern): 在一个解决方案中结合两个或多个模式，以解决一般或重复发生的问题。
结构型模式
适配器模式(Adapter pattern): 将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。对象适配器使用组合，类适配器使用多重继承。
桥接模式(Bridge pattern): 使用桥接模式通过将实现和抽象放在两个不同的类层次中而使它们可以独立改变。
组合模式(composite pattern): 允许你将对象组合成树形结构来表现”整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。
装饰者模式(decorator pattern): 动态地将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
外观模式(facade pattern): 提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
亨元模式(Flyweight Pattern): 如想让某个类的一个实例能用来提供许多”虚拟实例”，就使用蝇量模式。
代理模式(Proxy pattern): 为另一个对象提供一个替身或占位符以控制对这个对象的访问。
行为型模式
责任链模式(Chain of responsibility pattern): 通过责任链模式，你可以为某个请求创建一个对象链。每个对象依序检查此请求并对其进行处理或者将它传给链中的下一个对象。该处理方式类似递归方式把所有请求都遍历一次。
命令模式(Command pattern): 将”请求”封闭成对象，以便使用不同的请求,队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。
解释器模式(Interpreter pattern): 使用解释器模式为语言创建解释器。是一个简单语法分析工具，它最显著的优点就是扩展性，修改语法规则只要修改相应的非终结符表达式就可以了，若扩展语法，则只要增加非终结符类就可以了。
迭代器模式(iterator pattern): 提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。迭代器模式也有点没落了，基本上很少有项目再独立写迭代器了，直接使用 List 或者 Map 就可以完整的解决问题。
中介者模式(Mediator pattern) : 使用中介者模式来集中相关对象之间复杂的沟通和控制方式。多个对象有依赖关系，但是依赖的行为尚不确定或者有发生改变的可能，在这种情况下一般建议采用中介者模式，降低变更引起的风险扩散。
备忘录模式(Memento pattern): 当你需要让对象返回之前的状态时(例如，你的用户请求”撤销”)，你使用备忘录模式。
观察者模式(observer pattern): 在对象之间定义一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象都会收到通知，并自动更新。Observable 相当于生产者（添加、删除、通知观察者），Observer相当于消费者 。
状态模式(State pattern): 允许对象在内部状态改变时改变它的行为，对象看起来好象改了它的类。通过状态机来管理各种状态。
策略模式(strategy pattern): 定义了算法族，分别封闭起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
模板方法模式(Template pattern): 在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。JdbcTemple等都是使用模板模式实现各种操作。
访问者模式(visitor pattern): 当你想要为一个对象的组合增加新的能力，且封装并不重要时，就使用访问者模式。访问者模式是对迭代器模式的扩充，可以遍历不同的对象，然后执行不同的操作，也就是针对访问的对象不同，执行不同的操作。具体访问者、抽象元素 、具体元素visitor.visit(this)、结构对象。通过该模式可以方便实现拦截器。
设计模式的六大原则
1、开闭原则（Open Close Principle）
Software entities like classes, modules and functions should be open for extension but closed for modifications.
一个软件实体应该对扩展开放，对修改关闭。
开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，通过继承重写方法实现扩展，也不是修改实现类的方法。开闭原则是最基础的一个原则，后面（单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则）都是开闭原则的具体形态，也就是说前五个原则就是指导设计的工具和方法，而开闭原则才是其精神领袖，换一个角度来理解，依照 Java 语言的称谓，开闭原则是抽象类，其他五大原则则是具体的实现类。
2、里氏代换原则（Liskov Substitution Principle）
第一个定义，最正宗的定义：If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.
第二个定义，functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
3、依赖倒转原则（Dependence Inversion Principle）
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。
4、接口隔离原则（Interface Segregation Principle）
第一种定义: Clients should not be forced to depend upon interfaces that they don't use.
客户端不应该依赖它不需用的接口。
第二种定义：The dependency of one class to another one should depend on the smallest possible interface.
类间的依赖关系应该建立在最小的接口上。
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
5、迪米特法则，又称最少知道原则（Demeter Principle）
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
迪米特法则就要求类“小气”一点，尽量不要对外公布太多的 public 方法和非静态的 public 变量，尽量内敛，多使用private、package-private、 protected 等访问权限。
迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高，其要求的结果就是产生了大量的中转或跳转类，类只能和朋友交流，朋友少了你业务跑不起来，朋友多了，项目管理就复杂，大家在使用的时候做相互权衡吧。
6、单一职责原则（Single Responsibility Principle）
There should never be more than one reason for a class to change。
不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。
单一职责原则最难划分的就是职责，一个职责一个接口，但是问题是“职责”是一个没有量化的标准，一个类到底要负责那些职责？这些职责怎么细化？细化后是否都要有一个接口或类？