经常使用设计模式之单例模式和工厂模式

•  单例模式

java中单例模式是一种常见的设计模式，单例模式的写法有好几种，这里主要介绍三种：懒汉式单例、饿汉式单例、登记式单例。

　　单例模式有如下特色：

　　1、单例类只能有一个实例。

　　2、单例类必须本身建立本身的惟一实例。

　　3、单例类必须给全部其余对象提供这一实例。

　　单例模式确保某个类只有一个实例，并且自行实例化并向整个系统提供这个实例。在计算机系统中，线程池、缓存、日志对象、对话框、打印机、显卡的驱动程序对象常被设计成单例。这些应用都或多或少具备资源管理器的功能。每台计算机能够有若干个打印机，但只能有一个Printer Spooler，以免两个打印做业同时输出到打印机中。每台计算机能够有若干通讯端口，系统应当集中管理这些通讯端口，以免一个通讯端口同时被两个请求同时调用。总之，选择单例模式就是为了不不一致状态，避免政出多头。

一 ： 懒汉式 单例
1. //懒汉式单例类.在第一次调用的时候实例化本身   
2. public class Singleton {  
3.     private Singleton() {}  
4.     private static Singleton single=null;  
5.     //静态工厂方法   
6.     public static Singleton getInstance() {  
7.          if (single == null) {    
8.              single = new Singleton();  
9.          }    
10.         return single;  
11.     }  
12. }  
1、在getInstance方法上加同步
1. public static synchronized Singleton getInstance() {  
2.          if (single == null) {    
3.              single = new Singleton();  
4.          }    
5.         return single;  
6. }  
2、双重检查锁定
1. public static Singleton getInstance() {  
2.         if (singleton == null) {    
3.             synchronized (Singleton.class) {    
4.                if (singleton == null) {    
5.                   singleton = new Singleton();   
6.                }    
7.             }    
8.         }    
9.         return singleton;   
10.     }  
 
3、静态内部类
1. public class Singleton {    
2.     private static class LazyHolder {    
3.        private static final Singleton INSTANCE = new Singleton();    
4.     }    
5.     private Singleton (){}    
6.     public static final Singleton getInstance() {    
7.        return LazyHolder.INSTANCE;    
8.     }    
9. } 
 
二： 饿汉式单例
1. /饿汉式单例类.在类初始化时，已经自行实例化   
2. public class Singleton1 {  
3.     private Singleton1() {}  
4.     private static final Singleton1 single = new Singleton1();  
5.     //静态工厂方法   
6.     public static Singleton1 getInstance() {  
7.         return single;  
8.     }  
9. }  
  

饿汉式和懒汉式区别

从名字上来讲，饿汉和懒汉，

饿汉就是类一旦加载，就把单例初始化完成，保证getInstance的时候，单例是已经存在的了，而懒汉比较懒，只有当调用getInstance的时候，才回去初始化这个单例。另外从如下两点再区分如下这两种方式：

一、线程安全：

饿汉式天生就是线程安全的，能够直接用于多线程而不会出现问题，

懒汉式自己是非线程安全的，为了实现线程安全有几种写法，分别是上面的一、二、3，这三种实如今资源加载和性能方面有些区别。

二、资源加载和性能：

饿汉式在类建立的同时就实例化一个静态对象出来，无论以后会不会使用这个单例，都会占据必定的内存，可是相应的，在第一次调用时速度也会更快，由于其资源已经初始化完成，

而懒汉式顾名思义，会延迟加载，在第一次使用该单例的时候才会实例化对象出来，第一次调用时要作初始化，若是要作的工做比较多，性能上会有些延迟，以后就和饿汉式同样了。

至于一、二、3这三种实现又有些区别，

第1种，在方法调用上加了同步，虽然线程安全了，可是每次都要同步，会影响性能，毕竟99%的状况下是不须要同步的，

第2种，在getInstance中作了两次null检查，确保了只有第一次调用单例的时候才会作同步，这样也是线程安全的，同时避免了每次都同步的性能损耗

第3种，利用了classloader的机制来保证初始化instance时只有一个线程，因此也是线程安全的，同时没有性能损耗，因此通常我倾向于使用这一种。

•  工厂模式

在面向对象编程中, 最一般的方法是一个new操做符产生一个对象实例,new操做符就是用来构造对象实例的。可是在一些状况下, new操做符直接生成对象会带来一些问题。举例来讲, 许多类型对象的创造须要一系列的步骤: 你可能须要计算或取得对象的初始设置; 选择生成哪一个子对象实例; 或在生成你须要的对象以前必须先生成一些辅助功能的对象。 在这些状况,新对象的创建就是一个 “过程”，不只是一个操做，像一部大机器中的一个齿轮传动。

模式的问题：你如何能轻松方便地构造对象实例，而没必要关心构造对象实例的细节和复杂过程呢？

解决方案：创建一个工厂来建立对象

实现：

1、引言

    1）尚未工厂时代：假如尚未工业革命，若是一个客户要一款宝马车,通常的作法是客户去建立一款宝马车，而后拿来用。

    2）简单工厂模式：后来出现工业革命。用户不用去建立宝马车。由于客户有一个工厂来帮他建立宝马.想要什么车，这个工厂就能够建。好比想要320i系列车。工厂就建立这个系列的车。即工厂能够建立产品。

    3）工厂方法模式时代：为了知足客户，宝马车系列愈来愈多，如320i，523i,30li等系列一个工厂没法建立全部的宝马系列。因而由单独分出来多个具体的工厂。每一个具体工厂建立一种系列。即具体工厂类只能建立一个具体产品。可是宝马工厂仍是个抽象。你须要指定某个具体的工厂才能生产车出来。

   4）抽象工厂模式时代：随着客户的要求愈来愈高，宝马车必须配置空调。因而这个工厂开始生产宝马车和须要的空调。

   最终是客户只要对宝马的销售员说：我要523i空调车，销售员就直接给他523i空调车了。而不用本身去建立523i空调车宝马车.

   这就是工厂模式。

2、分类 

        工厂模式主要是为建立对象提供过渡接口，以便将建立对象的具体过程屏蔽隔离起来，达到提升灵活性的目的。 

工厂模式能够分为三类： 

1）简单工厂模式（Simple Factory） 

2）工厂方法模式（Factory Method） 

3）抽象工厂模式（Abstract Factory） 

 这三种模式从上到下逐步抽象，而且更具通常性。 

        GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Method）与抽象工厂模式（Abstract Factory）。

        将简单工厂模式（Simple Factory）看为工厂方法模式的一种特例，二者归为一类。 

3、区别 

工厂方法模式：

一个抽象产品类，能够派生出多个具体产品类。   

一个抽象工厂类，能够派生出多个具体工厂类。   

每一个具体工厂类只能建立一个具体产品类的实例。

抽象工厂模式：

多个抽象产品类，每一个抽象产品类能够派生出多个具体产品类。   

一个抽象工厂类，能够派生出多个具体工厂类。   

每一个具体工厂类能够建立多个具体产品类的实例。   

区别：

工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。   

工厂方法模式的具体工厂类只能建立一个具体产品类的实例，而抽象工厂模式能够建立多个。

二者皆可。 

 4、简单工厂模式 

创建一个工厂（一个函数或一个类方法）来制造新的对象。

分布说明引子：从无到有。客户本身建立宝马车，而后拿来用。

客户须要知道怎么去建立一款车,客户和车就紧密耦合在一块儿了.为了下降耦合,就出现了工厂类,把建立宝马的操做细节都放到了工厂里面去,客户直接使用工厂的建立工厂方法,传入想要的宝马车型号就好了,而没必要去知道建立的细节.这就是工业革命了：简单工厂模式

即咱们创建一个工厂类方法来制造新的对象。如图：

  简单工厂模式又称静态工厂方法模式。重命名上就能够看出这个模式必定很简单。它存在的目的很简单：定义一个用于建立对象的接口。 

      先来看看它的组成： 

         1) 工厂类角色：这是本模式的核心，含有必定的商业逻辑和判断逻辑，用来建立产品

         2) 抽象产品角色：它通常是具体产品继承的父类或者实现的接口。         

         3) 具体产品角色：工厂类所建立的对象就是此角色的实例。在java中由一个具体类实现。 

        

        下面咱们从开闭原则（对扩展开放；对修改封闭）上来分析下简单工厂模式。当客户再也不知足现有的车型号的时候，想要一种速度快的新型车，只要这种车符合抽象产品制定的合同，那么只要通知工厂类知道就能够被客户使用了。因此对产品部分来讲，它是符合开闭原则的；可是工厂部分好像不太理想，由于每增长一种新型车，都要在工厂类中增长相应的建立业务逻辑（createBMW(int type)方法须要新增case），这显然是违背开闭原则的。可想而知对于新产品的加入，工厂类是很被动的。对于这样的工厂类，咱们称它为全能类或者上帝类。 

        咱们举的例子是最简单的状况，而在实际应用中，极可能产品是一个多层次的树状结构。因为简单工厂模式中只有一个工厂类来对应这些产品，因此这可能会把咱们的上帝累坏了，也累坏了咱们这些程序员。

        因而工厂方法模式做为救世主出现了。 工厂类定义成了接口,而每新增的车种类型,就增长该车种类型对应工厂类的实现,这样工厂的设计就能够扩展了,而没必要去修改原来的代码。

5、工厂方法模式 

        工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它能够被子类继承。这样在简单工厂模式里集中在工厂方法上的压力能够由工厂方法模式里不一样的工厂子类来分担。 

工厂方法模式组成： 

       1)抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。 

       2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以建立对应的具体产品的对象。 

       3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中通常有抽象类或者接口来实现。 

       4)具体产品角色：具体工厂角色所建立的对象就是此角色的实例。在java中由具体的类来实现。 

 

       工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说，这样便分担了对象承受的压力；并且这样使得结构变得灵活 起来——当有新的产品产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生成，那么就能够被客户使用，而没必要去修改任何已有 的代码。能够看出工厂角色的结构也是符合开闭原则的！ 

  简单工厂模式又称静态工厂方法模式。重命名上就能够看出这个模式必定很简单。它存在的目的很简单：定义一个用于建立对象的接口。 

      先来看看它的组成： 

         1) 工厂类角色：这是本模式的核心，含有必定的商业逻辑和判断逻辑，用来建立产品

         2) 抽象产品角色：它通常是具体产品继承的父类或者实现的接口。         

         3) 具体产品角色：工厂类所建立的对象就是此角色的实例。在java中由一个具体类实现。 

        

        下面咱们从开闭原则（对扩展开放；对修改封闭）上来分析下简单工厂模式。当客户再也不知足现有的车型号的时候，想要一种速度快的新型车，只要这种车符合抽象产品制定的合同，那么只要通知工厂类知道就能够被客户使用了。因此对产品部分来讲，它是符合开闭原则的；可是工厂部分好像不太理想，由于每增长一种新型车，都要在工厂类中增长相应的建立业务逻辑（createBMW(int type)方法须要新增case），这显然是违背开闭原则的。可想而知对于新产品的加入，工厂类是很被动的。对于这样的工厂类，咱们称它为全能类或者上帝类。 

        咱们举的例子是最简单的状况，而在实际应用中，极可能产品是一个多层次的树状结构。因为简单工厂模式中只有一个工厂类来对应这些产品，因此这可能会把咱们的上帝累坏了，也累坏了咱们这些程序员。

        因而工厂方法模式做为救世主出现了。 工厂类定义成了接口,而每新增的车种类型,就增长该车种类型对应工厂类的实现,这样工厂的设计就能够扩展了,而没必要去修改原来的代码。

5、工厂方法模式 

        工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它能够被子类继承。这样在简单工厂模式里集中在工厂方法上的压力能够由工厂方法模式里不一样的工厂子类来分担。 

工厂方法模式组成： 

       1)抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。 

       2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以建立对应的具体产品的对象。 

       3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中通常有抽象类或者接口来实现。 

       4)具体产品角色：具体工厂角色所建立的对象就是此角色的实例。在java中由具体的类来实现。 

产品类：

1. abstract class BMW {  
2.     public BMW(){  
3.           
4.     }  
5. }  
6. public class BMW320 extends BMW {  
7.     public BMW320() {  
8.         System.out.println("制造-->BMW320");  
9.     }  
10. }  
11. public class BMW523 extends BMW{  
12.     public BMW523(){  
13.         System.out.println("制造-->BMW523");  
14.     }  
15. }  
   建立工厂类：
1. interface FactoryBMW {  
2.     BMW createBMW();  
3. }  
4.   
5. public class FactoryBMW320 implements FactoryBMW{  
6.   
7.     @Override  
8.     public BMW320 createBMW() {  
9.   
10.         return new BMW320();  
11.     }  
12.   
13. }  
14. public class FactoryBMW523 implements FactoryBMW {  
15.     @Override  
16.     public BMW523 createBMW() {  
17.   
18.         return new BMW523();  
19.     }  
20. }  
 客户类：
1. public class Customer {  
2.     public static void main(String[] args) {  
3.         FactoryBMW320 factoryBMW320 = new FactoryBMW320();  
4.         BMW320 bmw320 = factoryBMW320.createBMW();  
5.   
6.         FactoryBMW523 factoryBMW523 = new FactoryBMW523();  
7.         BMW523 bmw523 = factoryBMW523.createBMW();  
8.     }  
9. } 

    工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说，这样便分担了对象承受的压力；并且这样使得结构变得灵活 起来——当有新的产品产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生成，那么就能够被客户使用，而没必要去修改任何已有 的代码。能够看出工厂角色的结构也是符合开闭原则的！