设计模式
- 工厂模式
解决问题：在系统重构或增加产品时类的建立，如果类的建立放在主逻辑中。会导致修改工作量大而且在分工合作时代码结构化变差书写难度增加代码通用性变差
应用实例：1、您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。 2、Hibernate 换数据库只需换方言和驱动就可以。
优点： 1、一个调用者想创建一个对象，只要知道其名称就可以了。 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现，调用者只关心产品的接口。
缺点：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。
实现：
创建一个 Shape 接口和实现 Shape 接口的实体类。下一步是定义工厂类 ShapeFactory。这样主程序的调用只涉及shapeFactory而创建对象的接口，让其子类自己决定实例化哪一种产品，工厂模式使其创建过程延迟到子类进行。
- 抽象工厂模式
解决问题：当一个大功能有多种框架实现或多种实现方式时，使得该大功能兼容不同框架或实现方式（为什么是大功能，小功能直接是工厂模式就行了，大功能的实现底层是很复杂的类结构）
应用实例：一个系统开始要用mysql数据库存储，后来又要用oracle数据库存储，面向过程的话不仅主程序要改所有的存储相关函数实现也要改。而且更加过分如果该系统既要支持mysql又要支持oracle时如果没有抽象工厂主函数的逻辑实现就非常复杂。有了抽象工厂后，你只需要添加相应的oracle存储模块，增加抽象工厂支持产品就可以实现需求转变。
优点：当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。
缺点：产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。
实现：
创建 Shape 和 Color 接口和实现这些接口的实体类。下一步是创建抽象工厂类 AbstractFactory。接着定义工厂类 ShapeFactory 和 ColorFactory，这两个工厂类都是扩展了 AbstractFactory。然后创建一个工厂创造器/生成器类 FactoryProducer。
- 单例模式
解决问题：一个工具类被频繁使用，会造成该类被多次创建多次销毁，这样既浪费时间又浪费资源，然而在单线程下只需要一个给定的实例使用就可。于是使用一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。
应用实例: 通常都将dao层（数据库连接层）设置成单例，这样的话如果每次处理数据库中的数据都需要同一个对象去处理。就如一个班级只有一个班主任，有事就找他。
优点: 1、在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。 2、避免对资源的多重占用（比如写文件操作）。
缺点：没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。只有一个实例所有数据都需要同一个对象去处理的话，处理数据的性能完全得不到保证。多线程需要锁去保证安全。
单例模式构建方式：
1.饿汉模式
2.懒汉模式（Double Check）
3.静态内部类的单例模式
4.容器实现单例模式
5.序列化反序列化单例模式（readResolve）
6.枚举单例模式
实现：
我们将创建一个 SingleObject 类。SingleObject 类有它的私有构造函数和本身的一个静态实例。SingleObject 类提供了一个静态方法，供外界获取它的静态实例。SingletonPatternDemo，我们的演示类使用 SingleObject 类来获取 SingleObject 对象。
