常用设计者模式---工厂模式和单例模式

从今天起（2017.2.14），我要开始系统认真的啃基础，坚持下去，每天进步一点点。

一、什么是设计者模式（what）?

最早提出“设计模式”概念的是建筑设计大师亚力山大Alexander。在他的《建筑的永恒之道》里这样描述：模式是一条由三个部分组成的通用规则：它表示了一个特定环境、一类问题和一个解决方案之间的关系。每一个模式描述了一个不断重复发生的问题，以及该问题解决方案的核心设计。设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

二、设计模式的分类

总体来说设计模式分为三大类：创建型模式用来处理对象的创建过程；结构型模式用来处理类或者对象的组合；行为型模式用来对类或对象怎样交互和怎样分配职责进行描述。
创建型模式用来处理对象的创建过程，主要包含以下5种设计模式：
工厂方法模式（Factory Method Pattern）
抽象工厂模式（Abstract Factory Pattern）
建造者模式（Builder Pattern搜索）
原型模式（Prototype Pattern）
单例模式（Singleton Pattern）
 
结构型模式用来处理类或者对象的组合，主要包含以下7种设计模式：
适配器模式（Adapter Pattern）
桥接模式（Bridge Pattern）
组合模式（Composite Pattern）
装饰者模式（Decorator Pattern）
外观模式（Facade Pattern）
享元模式（Flyweight Pattern）
代理模式（Proxy Pattern）
 
行为型模式用来对类或对象怎样交互和怎样分配职责进行描述，主要包含以下11种设计模式：
责任链模式（Chain of Responsibility Pattern）
命令模式（Command Pattern）
解释器模式（Interpreter Pattern）
迭代器模式（Iterator Pattern）
中介者模式（Mediator Pattern）
备忘录模式（Memento Pattern）
观察者模式（Observer Pattern）
状态模式（State Pattern）
策略模式（Strategy Pattern）
模板方法模式（Template Method Pattern）
访问者模式（Visitor Pattern）

其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下：

三、设计模式六大原则

总原则－开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

1、单一职责原则
不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，否则就应该把类拆分。
2、里氏代换原则（Liskov Substitution Principle）
任何基类可以出现的地方，子类一定可以出现。里氏替换原则是继承复用的基石，只有当衍生类可以替换基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
里氏代换原则是对“开-闭”原则的补充。实现“开闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。里氏替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。
3、依赖倒转原则（Dependence Inversion Principle）
这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）
每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。所以上文中多次出现：降低依赖，降低耦合。
5、迪米特法则（最少知道原则）（Demeter Principle）
为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。
最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。
6、合成复用原则（Composite Reuse Principle）
原则是尽量使用合成/聚合的方式，而不是使用继承。

四、java23种设计模式之创建型

1、工厂方法模式

场景问题
　　举个生活中常见的例子——组装电脑，我们在组装电脑的时候，通常需要选择一系列的配件，比如CPU、硬盘、内存、主板、电源、机箱等。为讨论使用简单点，只考虑选择CPU和主板的问题。
　　事实上，在选择CPU的时候，面临一系列的问题，比如品牌、型号、针脚数目、主频等问题，只有把这些问题都确定下来，才能确定具体的CPU。
　　同样，在选择主板的时候，也有一系列问题，比如品牌、芯片组、集成芯片、总线频率等问题，也只有这些都确定了，才能确定具体的主板。

对于装机工程师而言，他只知道组装一台电脑，需要相应的配件，但是具体使用什么样的配件，还得由客户说了算。也就是说装机工程师只是负责组装，而客户负责选择装配所需要的具体的配件。因此，当装机工程师为不同的客户组装电脑时，只需要根据客户的装机方案，去获取相应的配件，然后组装即可。

源代码
CPU接口与具体实现

public interface Cpu {    public void calculate();}

public class IntelCpu implements Cpu {    /**     * CPU的针脚数     */    private int pins = 0;    public  IntelCpu(int pins){        this.pins = pins;    }    @Override    public void calculate() {        // TODO Auto-generated method stub        System.out.println("Intel CPU的针脚数：" + pins);    }}

public class AmdCpu implements Cpu {    /**     * CPU的针脚数     */    private int pins = 0;    public  AmdCpu(int pins){        this.pins = pins;    }    @Override    public void calculate() {        // TODO Auto-generated method stub        System.out.println("AMD CPU的针脚数：" + pins);    }}

主板接口与具体实现

public interface Mainboard {    public void installCPU();}

public class IntelMainboard implements Mainboard {    /**     * CPU插槽的孔数     */    private int cpuHoles = 0;    /**     * 构造方法，传入CPU插槽的孔数     * @param cpuHoles     */    public IntelMainboard(int cpuHoles){        this.cpuHoles = cpuHoles;    }    @Override    public void installCPU() {        // TODO Auto-generated method stub        System.out.println("Intel主板的CPU插槽孔数是：" + cpuHoles);    }}

public class AmdMainboard implements Mainboard {    /**     * CPU插槽的孔数     */    private int cpuHoles = 0;    /**     * 构造方法，传入CPU插槽的孔数     * @param cpuHoles     */    public AmdMainboard(int cpuHoles){        this.cpuHoles = cpuHoles;    }    @Override    public void installCPU() {        // TODO Auto-generated method stub        System.out.println("AMD主板的CPU插槽孔数是：" + cpuHoles);    }}

CPU与主板工厂类

public class CpuFactory {    public static Cpu createCpu(int type){        Cpu cpu = null;        if(type == 1){            cpu = new IntelCpu(755);        }else if(type == 2){            cpu = new AmdCpu(938);        }        return cpu;    }}

public class MainboardFactory {    public static Mainboard createMainboard(int type){        Mainboard mainboard = null;        if(type == 1){            mainboard = new IntelMainboard(755);        }else if(type == 2){            mainboard = new AmdMainboard(938);        }        return mainboard;    }}

装机工程师类与客户类运行结果如下：

public class ComputerEngineer {    /**     * 定义组装机需要的CPU     */    private Cpu cpu = null;    /**     * 定义组装机需要的主板     */    private Mainboard mainboard = null;    public void makeComputer(int cpuType , int mainboard){        /**         * 组装机器的基本步骤         */        //1:首先准备好装机所需要的配件        prepareHardwares(cpuType, mainboard);        //2:组装机器        //3:测试机器        //4：交付客户    }    private void prepareHardwares(int cpuType , int mainboard){        //这里要去准备CPU和主板的具体实现，为了示例简单，这里只准备这两个        //可是，装机工程师并不知道如何去创建，怎么办呢？                //直接找相应的工厂获取        this.cpu = CpuFactory.createCpu(cpuType);        this.mainboard = MainboardFactory.createMainboard(mainboard);                //测试配件是否好用        this.cpu.calculate();        this.mainboard.installCPU();    }}

public class Client {    public static void main(String[]args){        ComputerEngineer cf = new ComputerEngineer();        cf.makeComputer(1,1);    }}

运行结果如下：

观察上面结果就会看出问题。客户选择的是Intel的CPU针脚数为755，而选择的主板是AMD，主板上的CPU插孔是938，根本无法组装，这就是没有维护配件之间的关系造成的。该怎么解决这个问题呢？

2、抽象工厂模式

那么，是否可以使用同一个工厂等级结构来对付这些相同或者极为相似的产品等级结构呢？当然可以的，而且这就是抽象工厂模式的好处。同一个工厂等级结构负责三个不同产品等级结构中的产品对象的创建。

可以看出，一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象。显然，这时候抽象工厂模式比简单工厂模式、工厂方法模式更有效率。对应于每一个产品族都有一个具体工厂。而每一个具体工厂负责创建属于同一个产品族，但是分属于不同等级结构的产品。

由于这两个产品族的等级结构相同，因此使用同一个工厂族也可以处理这两个产品族的创建问题，这就是抽象工厂模式。

根据产品角色的结构图，就不难给出工厂角色的结构设计图

可以看出，每一个工厂角色都有两个工厂方法，分别负责创建分属不同产品等级结构的产品对象

在什么情况下应当使用抽象工厂模式
　　1.一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。


　　2.这个系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。


　　3.同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。（比如：Intel主板必须使用Intel CPU、Intel芯片组）


　　4.系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。

抽象工厂模式的优点
1、分离接口和实现
　　客户端使用抽象工厂来创建需要的对象，而客户端根本就不知道具体的实现是谁，客户端只是面向产品的接口编程而已。也就是说，客户端从具体的产品实现中解耦。

2、使切换产品族变得容易
　　因为一个具体的工厂实现代表的是一个产品族，比如上面例子的从Intel系列到AMD系列只需要切换一下具体工厂。


抽象工厂模式的缺点
不太容易扩展新的产品
　　如果需要给整个产品族添加一个新的产品，那么就需要修改抽象工厂，这样就会导致修改所有的工厂实现类。

http://www.cnblogs.com/java-my-life/archive/2012/03/28/2418836.html

3、单例模式

单例模式有以下特点：
1、单例类只能有一个实例。
2、单例类必须自己创建自己的唯一实例。

3、单例类必须给所有其他对象提供这一实例。

模式：根据实例化对象时机不同分为懒汉模式与饿汉模式。饿汉模式是单例类被加载时候就实例化一个对象交给自己的引用；懒汉模式时在调用取得实例方法的时候才会实例化对象。

首先要解释一下什么是延迟加载，延迟加载就是等到真真使用的时候才去创建实例，不用时不要去创建。从速度和反应时间角度来讲，非延迟加载（又称饿汉式）好；从资源利用效率上说，延迟加载（又称懒汉式）好。

使用场景

系统只需要一个实例对象。
需要频繁实例化且销毁的对象。
创建对象时耗时过多或者耗资源过多，但又经常用到的对象。
有状态的对象。
频繁访问数据库或文件的对象。

反过来说，如果一个类可以有几个实例共存，那么就没有必要使用单例类。java语言中的Runtime对象就是一个单例模式

这样的模式有几个好处：
1、某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。
2、省去了new操作符，降低了系统内存的使用频率，减轻GC压力。
3、有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。（比如一个军队出现了多个司令员同时指挥，肯定会乱成一团），所以只有使用单例模式，才能保证核心交易服务器独立控制整个流程。

**1、饿汉式单例

//饿汉式单例类.在类初始化时，已经自行实例化 public class Singleton1 {    private Singleton1() {}    private static final Singleton1 single = new Singleton1();    //静态工厂方法     public static Singleton1 getInstance() {        return single;    }}

Java语言中的单例类的一个最重要的特点是类的构造方法是私有的，从而避免外界利用构造方法直接创建出人意多飞实例。
优点：1.线程安全的2.在类加载的同时已经创建好一个静态对象,调用时反应速度快。缺点： 资源利用效率不高，可能getInstance永远不会执行到，但是执行了该类的其他静态方法或者加载了该类（class.forName），那么这个实例仍然初始化了

2、懒汉式单例

//懒汉式单例类.在第一次调用的时候实例化自己 public class Singleton {    private Singleton() {}    private static Singleton single=null;    //静态工厂方法     public static Singleton getInstance() {         if (single == null) {               single = new Singleton();         }          return single;    }}

但是以上懒汉式单例的实现没有考虑线程安全问题，它是线程不安全的，并发环境下很可能出现多个Singleton实例，要实现线程安全，有以下三种方式，都是对getInstance这个方法改造，保证了懒汉式单例的线程安全。

（1）在getInstance方法上加同步

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

线程安全解决了，高并发没解决。但是，synchronized关键字锁住的是这个对象，这样的用法，在性能上会有所下降，因为每次调用getInstance()，都要对对象上锁，事实上，只有在第一次创建对象的时候需要加锁，之后就不需要了，所以，这个地方需要改进。

（2）双重检查锁定

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

似乎解决了之前提到的问题，将synchronized关键字加在了内部，也就是说当调用的时候是不需要加锁的，只有在instance为null，并创建对象的时候才需要加锁，性能有一定的提升。但是，这样的情况，还是有可能有问题的，看下面的情况：在Java指令中创建对象和赋值操作是分开进行的，也就是说instance = new Singleton();语句是分两步执行的。但是JVM并不保证这两个操作的先后顺序，也就是说有可能JVM会为新的Singleton实例分配空间，然后直接赋值给instance成员，然后再去初始化这个Singleton实例。这样就可能出错了，我们以A、B两个线程为例：
a>A、B线程同时进入了第一个if判断
b>A首先进入synchronized块，由于instance为null，所以它执行instance = new Singleton();
c>由于JVM内部的优化机制，JVM先画出了一些分配给Singleton实例的空白内存，并赋值给instance成员（注意此时JVM没有开始初始化这个实例），然后A离开了synchronized块。
d>B进入synchronized块，由于instance此时不是null，因此它马上离开了synchronized块并将结果返回给调用该方法的程序。
e>此时B线程打算使用Singleton实例，却发现它没有被初始化，于是错误发生了。
（线程安全解决了，高并发解决。但假设现在有A、B线程同时调运getInstance，然后A进入了DBManager实例化，此时假设B已经进入if (null == mInstance)然后在等待A释放锁，但是问题来了，当A释放锁以后已经实例化了变量mInstance，B却傻逼的不知道，然后继续持有锁实例化一个新的对象）

如果使用双重检查锁定来实现懒汉式单例类，需要在静态成员变量instance之前增加修饰符volatile，被volatile修饰的成员变量只能在JDK 1.5及以上版本中才能正确执行。volatile关键字会屏蔽Java虚拟机所做的一些代码优化，会导致系统运行效率降低，所以这种写法的单例模式也不是一种牛叉的写法。
优点：1.资源利用率高
缺点：第一次加载是发应不快 ，由于java 内存模型一些原因偶尔会失败

（3）静态内部类：实际情况是，单例模式使用内部类来维护单例的实现，JVM内部的机制能够保证当一个类被加载的时候，这个类的加载过程是线程互斥的。这样当我们第一次调用getInstance的时候，JVM能够帮我们保证instance只被创建一次，并且会保证把赋值给instance的内存初始化完毕，这样我们就不用担心上面的问题。同时该方法也只会在第一次调用的时候使用互斥机制，这样就解决了低性能问题。这样我们暂时总结一个完美的单例模式：

public class Singleton {      private static class LazyHolder {         private static final Singleton INSTANCE = new Singleton();      }      private Singleton (){}      public static final Singleton getInstance() {         return LazyHolder.INSTANCE;      }  }

如下写法的亮点就在于这种写法使用了JVM本身机制保证线程安全问题；由于InstanceHolder是私有的，除了getInstance()之外没有办法访问它，因此它是懒汉式的；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖JDK版本。
至于1、2、3这三种实现又有些区别，
第1种，在方法调用上加了同步，虽然线程安全了，但是每次都要同步，会影响性能，毕竟99%的情况下是不需要同步的，
第2种，在getInstance中做了两次null检查，确保了只有第一次调用单例的时候才会做同步，这样也是线程安全的，同时避免了每次都同步的性能损耗
第3种，利用了classloader的机制来保证初始化instance时只有一个线程，所以也是线程安全的，同时没有性能损耗，所以一般我倾向于使用这一种。

饿汉式和懒汉式区别
1、从名字上来说，饿汉和懒汉，
饿汉就是类一旦加载，就把单例初始化完成，保证getInstance的时候，单例是已经存在的了
而懒汉比较懒，只有当调用getInstance的时候，才回去初始化这个单例。
另外从以下两点再区分以下这两种方式：
2、线程安全：
饿汉式天生就是线程安全的，可以直接用于多线程而不会出现问题，
懒汉式本身是非线程安全的，为了实现线程安全有几种写法，分别是上面的1、2、3，这三种实现在资源加载和性能方面有些区别。
3、资源加载和性能：
饿汉式在类创建的同时就实例化一个静态对象出来，不管之后会不会使用这个单例，都会占据一定的内存，但是相应的，在第一次调用时速度也会更快，因为其资源已经初始化完成，
而懒汉式顾名思义，会延迟加载，在第一次使用该单例的时候才会实例化对象出来，第一次调用时要做初始化，如果要做的工作比较多，性能上会有些延迟，之后就和饿汉式一样了。