浅谈设计模式(一)单例模式/工厂模式/模板方法模式/策略模式

(一) 单例模式

单例模式，在它的核心结构中只包含一个被称为单例的特殊类。通过单例模式可以保证系统中一个类只有一个实例。

特点：
1、单例类只能有一个实例。
2、单例类必须自己创建自己的唯一实例。
3、单例类必须给所有其他对象提供这一实例

单例模式的要点：
1，私有的构造方法
2，指向自己实例的私有静态引用
3，以自己实例为返回值的静态的公有的方法

单例模式根据实例化对象时机的不同分为两种：
一种是饿汉式单例，一种是懒汉式单例。

饿汉式单例在单例类被加载时候，就实例化一个对象交给自己的引用；而懒汉式在调用取得实例方法的时候才会实例化对象。

代码如下：

饿汉式单例:
public class Singleton {

private static Singleton singleton = new Singleton(); 

private Singleton(){} 

public static Singleton getInstance(){     
    return singleton;   
} 

}

懒汉式单例:

public class Singleton {   
    private static Singleton singleton; 

  private Singleton(){} 

  public static synchronized Singleton getInstance(){     
      if(singleton==null){       
          singleton = new Singleton();     
      }     
      return singleton;   
  } 
} 

单例模式还有一种比较常见的形式：双重锁的形式

public class Singleton{  
  private static volatile Singleton instance=null;  
  
  private Singleton(){    
    //do something  
  }  
  
  public static Singleton getInstance(){    
      if(instance==null){      
          synchronized(SingletonClass.class){        
              if(instance==null){          
                  instance=new Singleton();        
              }      
          }    
       }    
       return instance;  
   }
}


这个模式将同步内容下方到if内部，提高了执行的效率，不必每次获取对象时都进行同步，只有第一次才同步，创建了以后就没必要了。
这种模式中双重判断加同步的方式，比上面例子中的效率大大提升，因为如果单层if判断，在服务器允许的情况下，假设有一百个线程，耗费的时间为100*（同步判断时间+if判断时间），而如果双重if判断，100的线程可以同时if判断，理论消耗的时间只有一个if判断的时间。

所以如果面对高并发的情况，而且采用的是懒汉模式，最好的选择就是双重判断加同步的方式。

单例模式的优点：

1，在内存中只有一个对象，节省内存空间。
2，避免频繁的创建销毁对象，可以提高性能。
3，避免对共享资源的多重占用。
4，可以全局访问。

单例模式的缺点：

1，扩展困难，由于getInstance静态函数没有办法生成子类的实例。如果要拓展，只有重写那个类。
2，隐式使用引起类结构不清晰。
3，可能会导致程序内存泄露的问题。

适用场景：

由于单例模式的以上优点，所以是编程中用的比较多的一种设计模式。以下为使用单例模式的场景：
1，需要频繁实例化然后销毁的对象。
2，创建对象时耗时过多或者耗资源过多，但又经常用到的对象。
3，资源共享的情况下，避免由于资源操作时导致的性能或损耗等
4，控制资源的情况下，方便资源之间的互相通信。

单例模式注意事项：

1.只能使用单例类提供的方法得到单例对象，不要使用反射，否则将会实例化一个新对象。
2.不要做断开单例类对象与类中静态引用的危险操作。
3.多线程使用单例使用共享资源时，注意线程安全问题。

关于Java中单例模式的一些常见问题：

一.单例模式的对象长时间不用会被jvm垃圾收集器收集吗？
除非人为地断开单例中静态引用到单例对象的联接，否则jvm垃圾收集器是不会回收单例对象的。
JVM卸载类的判定条件如下：
1，该类所有的实例都已经被回收，也就是java堆中不存在该类的任何实例。
2，加载该类的ClassLoader已经被回收。
3，该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。
只有三个条件都满足，jvm才会在垃圾收集的时候卸载类。显然，单例的类不满足条件一，因此单例类也不会被回收。

二.在一个jvm中会出现多个单例吗？
在分布式系统、多个类加载器、以及序列化的的情况下，会产生多个单例。那么在同一个jvm中，会不会产生单例呢？使用单例提供的getInstance()方法只能得到同一个单例，除非是使用反射方式，将会得到新的单例。
代码如下：

Class c = Class.forName(Singleton.class.getName()); 

Constructor ct = c.getDeclaredConstructor(); 

ct.setAccessible(true); 

Singleton singleton = (Singleton)ct.newInstance();

这样，每次运行都会产生新的单例对象。所以运用单例模式时，一定注意不要使用反射产生新的单例对象。

三.在getInstance()方法上同步有优势还是仅同步必要的块更优优势？

因为锁定仅仅在创建实例时才有意义，然后其他时候实例仅仅是只读访问的，因此只同步必要的块的性能更优，并且是更好的选择。
缺点：只有在第一次调用的时候，才会出现生成2个对象，才必须要求同步。而一旦singleton 不为null，系统依旧花费同步锁开销，有点得不偿失。

四.单例类可以被继承吗
根据单例实例构造的时机和方式不同，单例模式还可以分成几种。但对于这种通过私有化构造函数，静态方法提供实例的单例类而言，是不支持继承的。
这种模式的单例实现要求每个具体的单例类自身来维护单例实例和限制多个实例的生成。但可以采用另外一种实现单例的思路：登记式单例，来使得单例对继承的开放。典型列子Spring IOC实现原理 。

(二) 工厂模式

这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。

工厂模式根据抽象程度的不同分为三种：
1.简单工厂模式（也叫静态工厂模式）
2.工厂方法模式（也叫多形性工厂）
3.抽象工厂模式（也叫工具箱）

简单工厂模式:
实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。

工厂方法模式:
工厂方法是粒度很小的设计模式，因为模式的表现只是一个抽象的方法。 提前定义用于创建对象的接口，让子类决定实例化具体的某一个类，即在工厂和产品中间增加接口，工厂不再负责产品的创建，由接口针对不同条件返回具体的类实例，由具体类实例去实现。

抽象工厂模式:
当有多个抽象角色时使用的一种工厂模式。抽象工厂模式可以向客户端提供一个接口，使客户端在不必指定产品的具体的情况下，创建多个产品对象。它有多个抽象产品类，每个抽象产品类可以派生出多个具体产品类，一个抽象工厂类，可以派生出多个具体工厂类，每个具体工厂类可以创建多个具体产品类的实例。

工厂方法模式应该在实际中用的较多，我们以工厂方法模式举例

抽象的产品类：定义car 交通工具类

public interface Car {  
     void gotowork();
}

定义实际的产品类，总共定义两个，bike 和bus 分别表示不同的交通工具类

public class Bike implements Car {  
    @Override  
    public void goToWork() {    
        System.out.println("骑自行车去上班！");  
    } 
}

public class Bus implements Car {  
    @Override  
    public void goToWork() {    
        System.out.println("坐公交车去上班！");  
    } 
}

定义抽象的工厂接口

public interface ICarFactory {  
    Car getCar(); 
}

具体的工厂子类，分别为每个具体的产品类创建不同的工厂子类

public class BikeFactory implements ICarFactory {  
    @Override  
    public Car getCar() {    
        return new Bike();  
    } 
}

public class BusFactory implements ICarFactory {  
    @Override  
    public Car getCar() {    
        return new Bus();  
    } 
}

简单的测试类，来验证不同的工厂能够产生不同的产品对象

public class TestFactory {  
    @Test  
    public void test() {    
        ICarFactory factory = null;    
        // bike    
        factory = new BikeFactory();    
        Car bike = factory.getCar();    
        bike.goToW    ork(); //骑自行车去上班！   
        // bus    
        factory = new BusFactory();    
        Car bus = factory.getCar();    
        bus. goToWork();   //坐公交车去上班！  
    } 
}

工厂模式的优点：

    1、一个调用者想创建一个对象，只要知道其名称就可以了，降低了耦合度。
    2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。使得代码结构更加清晰。
    3、屏蔽产品的具体实现，调用者只关心产品的接口。

工厂模式的缺点：

    每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。所以对于简单对象来说，使用工厂模式反而增加了复杂度。

工厂模式的适用场景：

    1， 一个对象拥有很多子类。
    2， 创建某个对象时需要进行许多额外的操作。
    3， 系统后期需要经常扩展，它把对象实例化的任务交由实现类完成，扩展性好。

关于Java中的工厂模式的一些常见问题：

    1.利用父类的向下转型（使用父类类型的引用指向子类的对象）是可以达到类似于工厂模式的效果的，那为什么还要用工厂模式呢？
   把指向子类对象的父类引用赋给子类引用叫做向下转型，如： 

Class Student extends Person 

Person s = new Student();  
Student a = (Student)s;

使用向下转型在客户端实例化子类的时候，严重依赖具体的子类的名字。当我们需要更改子类的构造方法的时候，比如增加一个参数，或者更改了子类的类名，所有的new出来的子类都需要跟着更改。
但如果我们使用工厂模式，我们仅仅需要在工厂中修改一下new的代码，其余项目中用到此实例的都会跟着改，而不需要我们手动去操作。

总结：
无论是简单工厂模式、工厂方法模式还是抽象工厂模式，它们本质上都是将不变的部分提取出来，将可变的部分留作接口，以达到最大程度上的复用。

(三) 模板方法模式

定义一个操作中算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变算法的结构即可重定义该算法中的某些特定步骤。

类型：行为类模式

类图：

事实上，模版方法是编程中一个经常用到的模式。先来看一个例子，某日，程序员A拿到一个任务：给定一个整数数组，把数组中的数由小到大排序，然后把排序之后的结果打印出来。经过分析之后，这个任务大体上可分为两部分，排序和打印，打印功能好实现，排序就有点麻烦了。但是A有办法，先把打印功能完成，排序功能另找人做。

abstract class AbstractSort {  

  /** 
  * 将数组array由小到大排序 
  * @param array 
  */  
  protected abstract void sort(int[] array); 

  public void showSortResult(int[] array){ 
    this.sort(array); 
    System.out.print("排序结果："); 
    for (int i = 0; i < array.length; i++){ 
      System.out.printf("%3s", array[i]); 
    } 
  } 
}

写完后，A找到同事B说：有个任务，主要逻辑我已经写好了，你把剩下的逻辑实现一下吧。于是把AbstractSort类给B，让B写实现。B拿过来一看，太简单了，10分钟搞定，代码如下：

class ConcreteSort extends AbstractSort {  

    @Override 
    protected void sort(int[] array){ 
      for(int i=0; i<array.length-1; i++){ 
        selectSort(array, i); 
      } 
    } 

    private void selectSort(int[] array, int index) { 
      int MinValue = 32767; // 最小值变量 
      int indexMin = 0; // 最小值索引变量 
      int Temp; // 暂存变量 
      for (int i = index; i < array.length; i++) { 
        if (array[i] < MinValue){ // 找到最小值 
          MinValue = array[i]; // 储存最小值 
          indexMin = i;  
        } 
      } 
      Temp = array[index]; // 交换两数值 
      array[index] = array[indexMin]; 
      array[indexMin] = Temp; 
    } 
  }

写好后交给A，A拿来一运行：

public class Client {  
  public static int[] a = { 10, 32, 1, 9, 5, 7, 12, 0, 4, 3 }; 
  // 预设数据数组 
  public static void main(String[] args){ 
    AbstractSort s = new ConcreteSort(); 
    s.showSortResult(a); 
  } 
}

运行结果：
排序结果： 0 1 3 4 5 7 9 10 12 32
运行正常。行了，任务完成。这就是模版方法模式。

模版方法模式的结构
模版方法模式由一个抽象类和一个（或一组）实现类通过继承结构组成
抽象类中的方法分为三种：
1.抽象方法：父类中只声明但不加以实现，而是定义好规范，然后由它的子类去实现。
2.模版方法：由抽象类声明并加以实现。一般来说，模版方法调用抽象方法来完成主要的逻辑功能，并且，模版方法大多会定义为final类型，指明主要的逻辑功能在子类中不能被重写。
3.钩子方法：由抽象类声明并加以实现。但是子类可以去扩展，子类可以通过扩展钩子方法来影响模版方法的逻辑。

实现类用来实现细节。抽象类中的模版方法正是通过实现类扩展的方法来完成业务逻辑。只要实现类中的扩展方法通过了单元测试，在模版方法正确的前提下，整体功能一般不会出现大的错误。

模版方法的优点及适用场景

    容易扩展。一般来说，抽象类中的模版方法是不易反生改变的部分，而抽象方法是容易反生变化的部分，因此通过增加实现类一般可以很容易实现功能的扩展，符合开闭原则。
  便于维护。对于模版方法模式来说，正是由于他们的主要逻辑相同，才使用了模版方法，假如不使用模版方法，任由这些相同的代码散乱的分布在不同的类中，维护起来是非常不方便的。
  比较灵活。因为有钩子方法，因此，子类的实现也可以影响父类中主逻辑的运行。但是，在灵活的同时，由于子类影响到了父类，违反了里氏替换原则，也会给程序带来风险。这就对抽象类的设计有了更高的要求。
  在多个子类拥有相同的方法，并且这些方法逻辑相同时，可以考虑使用模版方法模式。在程序的主框架相同，细节不同的场合下，也比较适合使用这种模式。

(四) 策略模式

定义一组算法，将每个算法都封装起来，并且使他们之间可以互换。
类型：行为类模式
类图：

    策略模式是对算法的封装，把一系列的算法分别封装到对应的类中，并且这些类实现相同的接口，相互之间可以替换。在前面说过的模版方法模式中，也是关注对算法的封装。
    对照类图可以看到，策略模式与模版方法模式的区别仅仅是多了一个单独的封装类Context，它与模版方法模式的区别在于：在模版方法模式中，调用算法的主体在抽象的父类中，而在策略模式中，调用算法的主体则是封装到了封装类Context中，抽象策略Strategy一般是一个接口，目的只是为了定义规范，里面一般不包含逻辑。
    其实，这只是通用实现，而在实际编程中，因为各个具体策略实现类之间难免存在一些相同的逻辑，为了避免重复的代码，我们常常使用抽象类来担任Strategy的角色，在里面封装公共的代码，因此，在很多应用的场景中，在策略模式中一般会看到模版方法模式的影子。

策略模式的结构
1.封装类：也叫上下文，对策略进行二次封装，目的是避免高层模块对策略的直接调用。
2.抽象策略：通常情况下为一个接口，当各个实现类中存在着重复的逻辑时，则使用象类来封装这部分公共的代码，此时，策略模式看上去更像是模版方法模式。
3.具体策略：具体策略角色通常由一组封装了算法的类来担任，这些类之间可以根据需要自由替换。

策略模式代码实现

interface IStrategy { 
    public void doSomething(); 
}


class ConcreteStrategy1 implements IStrategy { 

    public void doSomething() { 
      System.out.println("具体策略1"); 
    } 
} 
class ConcreteStrategy2 implements IStrategy { 

    public void doSomething() { 
      System.out.println("具体策略2"); 
    } 
} 

class Context { 
    private IStrategy strategy; 

    public Context(IStrategy strategy){ 
      this.strategy = strategy; 
    } 

    public void execute(){ 
      strategy.doSomething(); 
    } 
 } 

 public class Client { 
    public static void main(String[] args){ 
      Context context; 
      System.out.println("-----执行策略1-----"); 
      context = new Context(new ConcreteStrategy1()); 
      context.execute(); 

      System.out.println("-----执行策略2-----"); 
      context = new Context(new ConcreteStrategy2()); 
      context.execute(); 
    } 
 }

策略模式的优缺点
策略模式的主要优点有：
(一) 策略类之间可以自由切换，由于策略类实现自同一个抽象，所以他们之间可以自由切换。
(二) 易于扩展，增加一个新的策略对策略模式来说非常容易，基本上可以在不改变原有代码的基础上进行扩展。
(三) 避免使用多重条件，如果不使用策略模式，对于所有的算法，必须使用条件语句进行连接，通过条件判断来决定使用哪一种算法，在上一篇文章中我们已经提到，使用多重条件判断是非常不容易维护的。

策略模式的缺点主要有两个：
(一) 维护各个策略类会给开发带来额外开销，可能大家在这方面都有经验：一般来说，策略类的数量超过5个，就比较令人头疼了。
(二) 必须对客户端（调用者）暴露所有的策略类，因为使用哪种策略是由客户端来决定的，因此，客户端应该知道有什么策略，并且了解各种策略之间的区别，否则，后果很严重。例如，有一个排序算法的策略模式，提供了快速排序、冒泡排序、选择排序这三种算法，客户端在使用这些算法之前，是不是先要明白这三种算法的适用情况？再比如，客户端要使用一个容器，有链表实现的，也有数组实现的，客户端是不是也要明白链表和数组有什么区别？

适用场景:

   做面向对象设计的，对策略模式一定很熟悉，因为它实质上就是面向对象中的继承和多态，在看完策略模式的通用代码后，我想，即使之前从来没有听说过策略模式，在开发过程中也一定使用过它吧？至少在在以下两种情况下，大家可以考虑使用策略模式：

(一) 几个类的主要逻辑相同，只在部分逻辑的算法和行为上稍有区别的情况。
(二) 有几种相似的行为，或者说算法，客户端需要动态地决定使用哪一种，那么可以使用策略模式，将这些算法封装起来供客户端调用。

策略模式是一种简单常用的模式，我们在进行开发的时候，会经常有意无意地使用它，一般来说，策略模式不会单独使用，跟模版方法模式、工厂模式等混合使用的情况比较多。