创建型模式

（一）工厂方法模式

1．简单工厂模式

简单工厂模式并不属于23种设计模式,更像编码风格,后面的工厂方法模式和抽象工厂模式是简单工厂模式延伸过来的.

工厂类负责创建的对象比较少, 客户端只知道传入工厂类的参数,对于如何创建对象(逻辑)不关心

优点

只需要传入一个正确的参数,就可以获取你所需要的对象而无需知道创建的细节

缺点

1.增加新的产品,需要修改工厂类的判断逻辑,违背开闭原则(其实原则不能全部遵守,也不能不遵守),
2. 使用简单工程模式也增加了系统中类的个数,也增加了系统的复杂性.
3. 如果增加新的产品,我们是不得不修改逻辑的,产品类型非常多的时候,工厂逻辑就会过于复杂,不利于维护和扩展
4. 无法形成基于继承的等级结构

UML图

何时应该用工厂模式

根据具体业务需求。不要认为简单工厂是用switch case就觉得一无是处，也不要觉得抽象工厂比较高大上就到处套。我们使用设计模式是为了解决问题而不是炫技，所以根据三种工厂模式的特质，以及对未来扩展的预期，来确定使用哪种工厂模式

2．工厂方法模式

一个类通过其子类来指定创建哪个对象

工厂方法模式(Factory Method) 定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂方法使一个类的实例化延迟到其子类。

作为抽象工厂模式的孪生兄弟，工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个，也就是说工厂方法模式让实例化推迟到子类。

定义:
定义一个创建对象的接口,但让实现这个接口的类来决定实例化哪个类,工厂方法让类的实例化推迟到子类中进行

原则：
开放封闭原则


工厂模式适用的一些场景（不仅限于以下场景）


1. 对象的创建过程/实例化准备工作很复杂，需要初始化很多参数、查询数据库等。

2. 类本身有好多子类，这些类的创建过程在业务中容易发生改变，或者对类的调用容易发生改变。


优点

是简单工厂模式的进一步抽象和推广，既保持了简单工厂模式的优点（工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类。对于客户端来说，去除了与具体产品的依赖），而且克服了简单工厂的缺点（违背了开放封闭原则）。

缺点

1. 每增加一个产品，就需要增加一个产品工厂的类，增加了额外的开发。（用反射可以解决,但是反射的性能不是特别的好）。
2. 类的个数容易过多,增加复杂度,增加了系统的抽象性和理解难度
3. 工厂模式无法解决产品族和产品等级结构的问题
4.
应用

1. Collection中的iterator方法；
2. java.lang.Proxy#newProxyInstance()
3. java.lang.Object#toString()
4. java.lang.Class#newInstance()
5. java.lang.reflect.Array#newInstance()
6. java.lang.reflect.Constructor#newInstance()
7. java.lang.Boolean#valueOf(String)
8. java.lang.Class#forName()





工厂方法模式非常符合“开闭原则”，当需要增加一个新的产品时，我们只需要增加一个具体的产品类和与之对应的具体工厂即可，无须修改原有系统。同时在工厂方法模式中用户只需要知道生产产品的具体工厂即可，无须关系产品的创建过程，甚至连具体的产品类名称都不需要知道。虽然他很好的符合了“开闭原则”，但是由于每新增一个新产品时就需要增加两个类，这样势必会导致系统的复杂度增加。其UML结构图：


uml图



简介
工厂模式是为了解耦：把对象的创建和使用的过程分开。就是Class A 想调用 Class B ，那么A只是调用B的方法，而至于B的实例化，就交给工厂类。

其次，工厂模式可以降低代码重复。如果创建对象B的过程都很复杂，需要一定的代码量，而且很多地方都要用到，那么就会有很多的重复代码。我们可以这些创建对象B的代码放到工厂里统一管理。既减少了重复代码，也方便以后对B的创建过程的修改维护。（当然，我个人觉得也可以把这些创建过程的代码放到类的构造函数里，同样可以降低重复率，而且构造函数本身的作用也是初始化对象。不过，这样也会导致构造函数过于复杂，做的事太多，不符合java 的设计原则。）

由于创建过程都由工厂统一管理，所以发生业务逻辑变化，不需要找到所有需要创建B的地方去逐个修正，只需要在工厂里修改即可，降低维护成本。同理，想把所有调用B的地方改成B的子类B1，只需要在对应生产B的工厂中或者工厂的方法中修改其生产的对象为B1即可，而不需要找到所有的new B（）改为new B1()。

另外，因为工厂管理了对象的创建逻辑，使用者并不需要知道具体的创建过程，只管使用即可，减少了使用者因为创建逻辑导致的错误。

（二）抽象工厂模式

Abstract Factory

提供一个创建一系列相关或互相依赖对象的接口，而无需指定它们具体的类。
抽象工厂模式实现不同的产品族，并且实现产品等级结构,其它的应该和工厂方法模式没太大区别,仅仅是我,张俊杰个人认为.

比如说实现文章(Article)和视频(Video)
原则
LSP 里氏替换原则

场景
1. 应用层不依赖于产品类实例如何被创建,实现等细节
2. 强调一系列相关的产品对象(属于同一产品族)一起使用创建对象需要大量重复的代码
3. 提供了一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于具体的实现.

优点

1.改变具体工厂即可使用不同的产品配置，使改变一个应用的具体工厂变得很容易。

2.让具体的创建实例过程与客户端分离，客户端通过抽象接口操作实例，产品的具体类名也被具体工厂的实现分离。

3.抽象工厂模式最大的好处是易于交换产品系列，由于具体工厂类，例如 IFactory factory=new OracleFactory(); 在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它只需要改变具体工厂即可使用不同的产品配置。不管是任何人的设计都无法去完全防止需求的更改，或者项目的维护，那么我们的理想便是让改动变得最小、最容易，例如我现在要更改以上代码的数据库访问时，只需要更改具体的工厂即可。

4. 抽象工厂模式的另一个好处就是它让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操作实例，产品实现类的具体类名也被具体的工厂实现类分离，不会出现在客户端代码中。就像我们上面的例子，客户端只认识IUser和ILogin，至于它是MySQl里的表还是Oracle里的表就不知道了。

缺点

如果要新增方法，改动极大。

1. 如果你的需求来自增加功能，比如增加Login表，就有点太烦了。首先需要增加 ILogin，mysqlLogin,oracleLogin。 然后我们还要去修改工厂类： sqlFactory， mysqlFactory， oracleFactory 才可以实现，需要修改三个类，实在是有点麻烦。

2. 还有就是，客户端程序肯定不止一个，每次都需要声明sqlFactory factory=new MysqlFactory()， 如果有100个调用数据库的类，就需要更改100次sqlFactory factory=new oracleFactory()。
3. 增加了系统的难度,接口类多了


应用：

1. jdk中连接数据库的代码是典型的抽象工厂模式，每一种数据库只需提供一个统一的接口：Driver（工厂类），并实现其中的方法即可。不管是jdbc还是odbc都能够通过扩展产品线来达到连接自身数据库的方法。
2. java.util.Collection 接口中定义了一个抽象的 iterator() 方法，该方法就是一个工厂方法。对于 iterator() 方法来说 Collection 就是一个抽象工厂。


所谓抽象工厂模式就是提供一个接口，用于创建相关或者依赖对象的家族，而不需要明确指定具体类。他允许客户端使用抽象的接口来创建一组相关的产品，而不需要关系实际产出的具体产品是什么。这样一来，客户就可以从具体的产品中被解耦。它的优点是隔离了具体类的生成，使得客户端不需要知道什么被创建了，而缺点就在于新增新的行为会比较麻烦，因为当添加一个新的产品对象时，需要更加需要更改接口及其下所有子类。其UML结构图如下：

1．三种工厂模式关键点

三种工厂的实现是越来越复杂的

1. 简单工厂通过构造时传入的标识来生产产品，不同产品都在同一个工厂中生产，这种判断会随着产品的增加而增加，给扩展和维护带来麻烦
2. 工厂模式无法解决产品族和产品等级结构的问题
3. 抽象工厂模式中，一个工厂生产多个产品，它们是一个产品族，不同的产品族的产品派生于不同的抽象产品（或产品接口）

2．接口和抽象区别(工厂模式里面父类使用接口还是抽象)

在上面的代码中，都使用了接口来表达抽象工厂或者抽象产品，那么可以用抽象类吗？有何区别？
从功能上说，完全可以，甚至可以用接口来定义行为，用抽象类来抽象属性。抽象类更加偏向于属性的抽象，而用接口更加偏向行为的规范与统一。使用接口有更好的可扩展性和可维护性，更加灵活实现松散耦合，所以编程原则中有一条是针对接口编程而不是针对类编程

（三）单例模式

单例模式(Singleton) 保证一个类仅有一个实例，并提供一个访问它的全局访问点(我认为是获取这个单例的类的访问方法)。

原则
面向对象的三大特征之一:封装

场景

1. 通常，我们可以让一个全局变量使得一个对象被访问，但它不能防止你实例化多个对象，一个最好的办法就是，让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，而且它可以提供一个访问该实例的方法。
2. 需要频繁的进行创建和销毁的对象；
3. 创建对象时耗时过多或耗费资源过多，但又经常用到的对象；
4. 工具类对象；
5. 频繁访问数据库或文件的对象。

优点
唯一实例的受控访问。

缺点
饿汉式/懒汉式 多线程同时访问时可能造成多个实例。

应用
java.lang.Runtime； GUI中也有一些（java.awt.Toolkit#getDefaultToolkit() java.awt.Desktop#getDesktop()）

作用

第一、控制资源的使用，通过线程同步来控制资源的并发访问；
第二、控制实例产生的数量，达到节约资源的目的。
第二、作为通信媒介使用，也就是数据共享，它可以在不建立直接关联的条件下，让多个不相关的两个线程或者进程之间实现通信。


比如，数据库连接池的设计一般采用单例模式，数据库连接是一种数据库资源。软件系统中使用数据库连接池，主要是节省打开或者关闭数据库连接所引起的效率损耗，这种效率上的损耗还是非常昂贵的。当然，使用数据库连接池还有很多其它的好处，可以屏蔽不同数据数据库之间的差异，实现系统对数据库的低度耦合，也可以被多个系统同时使用，具有高可复用性，还能方便对数据库连接的管理等等。数据库连接池属于重量级资源，一个应用中只需要保留一份即可，既节省了资源又方便管理。所以数据库连接池采用单例模式进行设计会是一个非常好的选择。
在我们日常使用的在Windows中也有不少单例模式设计的组件，象常用的文件管理器。由于Windows操作系统是一个典型的多进程多线程系统，那么在创建或者删除某个文件的时候，就不可避免地出现多个进程或线程同时操作一个文件的现象。采用单例模式设计的文件管理器就可以完美的解决这个问题，所有的文件操作都必须通过唯一的实例进行，这样就不会产生混乱的现象。

再比如，每台计算机可以有若干个打印机，如果每一个进程或者线程都独立地使用打印机资源的话，那么我们打印出来的结果就有可能既包含这个打印任务的一部分，又包含另外一个打印任务的一部分。所以，大多数的操作系统最终为打印任务设计了一个单例模式的假脱机服务Printer Spooler，所有的打印任务都需要通过假脱机服务进行。

实际上，配置信息类、管理类、控制类、门面类、代理类通常被设计为单例类。像Java的Struts、Spring框架，.Net的Spring.Net框架，以及Php的Zend框架都大量使用了单例模式。


详解

Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。

在很多操作中，比如建立目录 数据库连接都需要这样的单线程操作。

还有, singleton能够被状态化; 这样，多个单态类在一起就可以作为一个状态仓库一样向外提供服务，比如，你要论坛中的帖子计数器，每次浏览一次需要计数，单态类能否保持住这个计数，并且能synchronize的安全自动加1，如果你要把这个数字永久保存到数据库，你可以在不修改单态接口的情况下方便的做到。

单例模式具备典型的3个特点：
1、只有一个实例。
2、自我实例化。
3、提供全局访问点。

因此当系统中只需要一个实例对象或者系统中只允许一个公共访问点，除了这个公共访问点外，不能通过其他访问点访问该实例时，可以使用单例模式。

单例模式的主要优点就是节约系统资源、提高了系统效率，同时也能够严格控制客户对它的访问。也许就是因为系统中只有一个实例，这样就导致了单例类的职责过重，违背了“单一职责原则”，同时也没有抽象类，所以扩展起来有一定的困难。

1．八种写法

6、双重检查[推荐用]

Double-Check概念对于多线程开发者来说不会陌生，如代码中所示，我们进行了两次if (singleton == null)检查，这样就可以保证线程安全了。这样，实例化代码只用执行一次，后面再次访问时，判断if (singleton == null)，直接return实例化对象。
优点：线程安全；延迟加载；效率较高。
7、静态内部类[推荐用]

这种方式跟饿汉式方式采用的机制类似，但又有不同。两者都是采用了类装载的机制来保证初始化实例时只有一个线程。不同的地方在饿汉式方式是只要Singleton类被装载就会实例化，没有Lazy-Loading的作用，而静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getInstance方法，才会装载SingletonInstance类，从而完成Singleton的实例化。
静态内部类是最安全的单例模式,类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。

原因：虚拟机会保证一个类的构造器()方法在多线程环境中被正确地加载，同步，如果多个线程同时去初始化一个类，那么只有一个线程去执行这个类的(类加载加载静态内部类的时候是线程互斥的.)




8、枚举[推荐用]

借助JDK1.5中添加的枚举来实现单例模式。不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。可能是因为枚举在JDK1.5中才添加，所以在实际项目开发中，很少见人这么写过。
优点
系统内存中该类只存在一个对象，节省了系统资源，对于一些需要频繁创建销毁的对象，使用单例模式可以提高系统性能。
缺点
当想实例化一个单例类的时候，必须要记住使用相应的获取对象的方法，而不是使用new，可能会给其他开发人员造成困扰，特别是看不到源码的时候。

1、饿汉式（静态常量）[可用]


优点：这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。
缺点：在类装载的时候就完成实例化，没有达到Lazy Loading的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费。

2、饿汉式（静态代码块）[可用]

这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面是一样的。
3、懒汉式(线程不安全)[不可用]

这种写法起到了Lazy Loading的效果，但是只能在单线程下使用。如果在多线程下，一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式。

4、懒汉式(线程安全，同步方法)[不推荐用]

解决上面第三种实现方式的线程不安全问题，做个线程同步就可以了，于是就对getInstance()方法进行了线程同步。
缺点：效率太低了，每个线程在想获得类的实例时候，执行getInstance()方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得该类实例，直接return就行了。方法进行同步效率太低要改进。
5、懒汉式(线程安全，同步代码块)[不可用]

由于第四种实现方式同步效率太低，所以摒弃同步方法，改为同步产生实例化的的代码块。但是这种同步并不能起到线程同步的作用。跟第3种实现方式遇到的情形一致，假如一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。

（四）建造者模式

将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.

用户只需指定需要建造的类型就可以得到它们,建造过程及细节不需要知道,但是我也同样可以建造出复杂的对象.

建造者模式就是如何一步一步构建一个包含多个组件的对象,相同的构建过程可以创建不同的产品,它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。


应用实例

1. 去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的”套餐”。
2. JAVA 中的 StringBuilder。


关键代码：
建造者：创建和提供实例，导演：管理建造出来的实例的依赖关系。


优点

1. 客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
2. 每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者， 用户使用不同的具体建造者即可得到不同的产品对象 。
3. 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
4. 增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，系统扩展方便，符合 “开闭原则”


缺点

1. 产生多余的builder对象
2. 产品必须有共同点，范围有限制。
3. 如内部变化复杂，会有很多的建造类。

主要解决：
主要解决在软件系统中，有时候面临着”一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。

使用场景：

1. 相同的方法，不同的执行顺序，产生不同的事件结果时，可以采用建造者模式。
2. 多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时，则可以使用该模式。
3. 产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用建造者模式非常合适。
4. 在对象创建过程中会使用到系统中的一些其他对象，这些对象在产品对象的创建过程中不易得到时，也可以采用建造者模式封装该对象的创建过程。该种场景只能是一个补偿方法，因为一个对象不容易获得，而在设计阶段竟然没有发觉，而要通过创建者模式柔化创建过程，本身已经违反设计的最初目标。


如果一个对象有非常复杂的内部结构(很多属性或者需要很复杂的步骤),并且想把创建对象的过程和使用分离.
1、需要生成的对象具有复杂的内部结构。
2、需要生成的对象内部属性本身相互依赖。
3、同时若几个产品之间存在较大的差异，则不适用建造者模式


建造者模式主要包含四个角色
Product（产品角色）： 一个具体的产品对象。
Builder（抽象建造者）： 创建一个Product对象的各个部件指定的抽象接口。
ConcreteBuilder（具体建造者）： 实现抽象接口，构建和装配各个部件。
Director（指挥者）： 构建一个使用Builder接口的对象。它主要是用于创建一个复杂的对象。它主要有两个作用，一是：隔离了客户与对象的生产过程，二是：负责控制产品对象的生产过程。

最佳实践
在使用建造者模式的时候考虑一下模板方法模式，别孤立地思考一个模式，僵化地套用一个模式会让你受害无穷！

1．建造者模式和工厂模式区别

建造者模式关注的是零件类型和装配工艺（顺序），这是它与工厂方法模式最大不同的地方，虽然同为创建类模式，但是注重点不同。

建造者模式更注重于方法调用的顺序, 工厂模式注重于创建产品, 另外一个创建对象的粒度不同,建造者模式可以创建一些复杂的产品,由各种复杂的部件组成,工厂模式创建出来的都是一个样子,

工厂模式注重的: 只要把一个对象创建出来就行了
建造者模式: 不只是要创建出这个产品,我还要知道这个产品都是由哪些部件组成的.

（五）原型模式

它主要应用与那些创建新对象的成本过大时。它的主要优点就是简化了新对象的创建过程，提高了效率，同时原型模式提供了简化的创建结构。

在我们应用程序可能有某些对象的结构比较复杂，但是我们又需要频繁的使用它们，如果这个时候我们来不断的新建这个对象势必会大大损耗系统内存的，这个时候我们需要使用原型模式来对这个结构复杂又要频繁使用的对象进行克隆。所以原型模式就是用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。

注意点
如果注意不到会出现bug问题
引用数据类型深克隆和浅克隆的方式,注意一定要深克隆,不然会出现数据上的问题,如果是浅克隆,你第一个对象属性修改了,第二个属性也跟着修改.

浅克隆：创建一个新对象，新对象的属性和原来对象完全相同，对于非基本类型属性，仍指向原有属性所指向的对象的内存地址。
深克隆：创建一个新对象，属性中引用的其他对象也会被克隆，不再指向原有对象地址。

使用场景
1、基本就是你需要从A的实例得到一份与A内容相同，但是又互不干扰的实例的话，就需要使用原型模式。
2、性能和安全要求的场景通过new产生一个对象需要非常繁琐的数据准备或访问权限，而且new了对象里面也没有数据,你还得去重新设置等等,
3.一个对象多个修改者的场景
一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。

4、结合使用
在实际项目中，原型模式很少单独出现，一般是和工厂方法模式一起出现，通过clone的方法创建一个对象，然后由工厂方法提供给调用者。原型模式已经与Java融为浑然一体，大家可以随手拿来使用。
优点
隐藏了对象创建的细节，大大提升了性能。不用重新初始化对象，而是动态的获得对象运行时的状态。

缺点:

深复制 or 浅复制

1、配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。

2、实现原型模式每个派生类都必须实现 Clone接口。

3、逃避构造函数的约束。