创建者模式主要思考如何创建一个对象，如何将对象的创建与使用分离。一般初级程序员都是new一个对象，然后紧接着使用这个对象，在某些场景中这样子是有问题的，需要使用创建者模式替代的（例如使用单例模式）。设计模式中提供了五种创建模型，分别是单例、原型、工厂方法、抽象工厂方法、创建者五种模式。

单例模式

这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。大白话讲就是只需要调用某个类的静态方法就可以获取唯一这个类唯一的对象，不需要对这个类进行new实例化对象，保证全局对象唯一。一般实现有饿汉式和懒汉式两种，下面分别介绍。

饿汉式（线程安全）

该方式在成员位置声明Singleton类型的静态变量，并创建Singleton类的对象instance。instance对象是随着类的加载而创建的。如果该对象足够大的话，而一直没有使用就会造成内存的浪费。

• 静态变量方式

  public class Singleton {
      //私有构造方法
      private Singleton() {}
  
      //在成员位置创建该类的对象
      private static Singleton instance = new Singleton();
  
      //对外提供静态方法获取该对象
      public static Singleton getInstance() {
          return instance;
      }
  }
  

• 静态代码块方式

  public class Singleton {
  
      //私有构造方法
      private Singleton() {}
  
      //在成员位置创建该类的对象
      private static Singleton instance;
  
      static {
          instance = new Singleton();
      }
  
      //对外提供静态方法获取该对象
      public static Singleton getInstance() {
          return instance;
      }
  }
  

懒汉式

• 非线程安全方式

  从上面代码我们可以看出该方式在成员位置声明Singleton类型的静态变量，并没有进行对象的赋值操作，那么什么时候赋值的呢？当调用getInstance()方法获取Singleton类的对象的时候才创建Singleton类的对象，这样就实现了懒加载的效果。但是，如果是多线程环境，会出现线程安全问题。

  public class Singleton {
      //私有构造方法
      private Singleton() {}
  
      //在成员位置创建该类的对象
      private static Singleton instance;
  
      //对外提供静态方法获取该对象
      public static Singleton getInstance() {
  		// 此处存在线程安全问题，如果有多个线程进入了判断将会创建多个对象
          if(instance == null) {
              instance = new Singleton();
          }
          return instance;
      }
  }
  

• 双重检查方式 DCL（线程安全）

  双重检查锁模式是一种非常好的单例实现模式，解决了单例、性能、线程安全问题。如果instance不使用volatile进行修饰，在多线程的情况下，可能会出现空指针问题，出现问题的原因是JVM在实例化对象的时候会进行优化和指令重排序操作。要解决双重检查锁模式带来空指针异常的问题，只需要使用 volatile 关键字, volatile 关键字可以保证可见性和有序性。这里不懂的话需要系统学习JMM原理，简单讲解一下就是JVM创建对象不是原子性的而是分为三步：1. 在堆内存开辟一个空间，2. 初始化内存空间，3. 对象引用指向该内存。如果第一个线程执行到第二步，其实instance依旧为null，但是如果此时有第二个线程进行 if(instance == null) {判断那么将重复创建对象。而使用volatile 关键字可以保证在读取instance的时候先等待写入完成，即等待第三步完成了才可以读取，用的是volatile 关键字的指令屏蔽原理来避免指令重排。

  public class Singleton { 
  
      //私有构造方法
      private Singleton() {}
      // volatile 关键字可以保证可见性和有序性。
      private static volatile Singleton instance;
  
     //对外提供静态方法获取该对象
      public static Singleton getInstance() {
  		//第一次判断，如果instance不为null，不进入抢锁阶段，直接返回实例
          if(instance == null) {
              synchronized (Singleton.class) {
                  //抢到锁之后再次判断是否为null
                  if(instance == null) {
                      instance = new Singleton();
                  }
              }
          }
          return instance;
      }
  }
  

• 静态内部类方式（线程安全）

  静态内部类单例模式中实例由内部类创建，由于 JVM 在加载外部类的过程中, 是不会加载静态内部类的, 只有内部类的属性/方法被调用时才会被加载, 并初始化其静态属性。静态属性由于被 static 修饰，保证只被实例化一次，并且严格保证实例化顺序。第一次加载Singleton类时不会去初始化INSTANCE，只有第一次调用getInstance，虚拟机加载SingletonHolder并初始化INSTANCE，这样不仅能确保线程安全，也能保证 Singleton 类的唯一性。静态内部类单例模式是一种优秀的单例模式，是开源项目中比较常用的一种单例模式。在没有加任何锁的情况下，保证了多线程下的安全，并且没有任何性能影响和空间的浪费。

  public class Singleton {
      //私有构造方法
      private Singleton() {}
  
      private static class SingletonHolder {
          private static final Singleton INSTANCE = new Singleton();
      }
      //对外提供静态方法获取该对象
      public static Singleton getInstance() {
          return SingletonHolder.INSTANCE;
      }
  }
  

• 极力推荐——枚举方式

  枚举类实现单例模式是极力推荐的单例实现模式，因为枚举类型是线程安全的，并且只会装载一次，设计者充分的利用了枚举的这个特性来实现单例模式，枚举的写法非常简单，而且枚举类型是所用单例实现中唯一一种不会被破坏的单例实现模式。枚举值都是 public static final的自身类型修饰的。

  /**
   * 枚举方式
   */
  public enum Singleton {
      INSTANCE;
  }
  ==============================================================
  // 等价于
  public class Singleton{
      public static final Singleton INSTANCE = new Singleton();
      // 且提供了获取INSTANCE的方法。。。。
  }
  

存在的问题（枚举类除外）

破坏单例模式：使上面定义的单例类（Singleton）可以创建多个对象，枚举方式除外。有两种方式:

• 序列化：将获取到的单例对象序列化之后再多次反序列化得到的多个对象其实不是同一个对象！
• 反射：通过两次暴力反射得到的两个单例对象其实并不相等！

解决办法：使用枚举类实现单例模式。反序列化被反射调用时直接返回单例类的实例，而不是返回新的new出来的对象实例。当通过反射方式调用构造方法进行创建创建时，直接抛异常。不运行此中操作。

例子

JDK的Runtime类使用的是单例模式的饿汉式中的静态变量方式实现的。

工厂方法模式

工厂方法模式都比较简单，难度高的是抽象工厂方法模式，个人认为工程方法模式的核心思路就是消费端或者讲客户端不要直接获取产品，不要直接与产品对象建立创建获取的关系，而是中间加一层工厂类，要什么产品对象问工厂拿，由工厂类生成产品对象。例如：设计一个咖啡类（Coffee），并定义其两个子类（美式咖啡（AmericanCoffee）和拿铁咖啡（LatteCoffee）；再设计一个咖啡店类（CoffeeStore），咖啡店具有点咖啡的功能。

大多数人会设计如下：

上述设计看似没有问题，但是现在又有一种新的咖啡叫做卡布奇洛（Cappuccilo），于是你需要修改CoffeeStore类。还记得我们所说的开闭原则吗？如果不记得请查阅上篇博客。在CoffeeStore类中如果创建的时候直接new该对象，就会对该对象耦合严重，假如我们要更换对象，所有new对象的地方都需要修改一遍，这显然违背了软件设计的开闭原则。如果我们使用工厂来生产对象，我们就只和工厂打交道就可以了，彻底和对象解耦，如果要更换对象，直接在工厂里更换该对象即可，达到了与对象解耦的目的；所以说，工厂模式最大的优点就是：解耦。工厂方法模式主要包括三种：简单工厂模式、工厂方法模式和抽象工厂模式，其中抽象工厂模式比较困难，我们另起一节介绍。

简单工厂模式

这种模式应该成为程序员的编程习惯，当一个产品有多种类型，且与另外一个类（消费端或者客户端）建立了关联，这个时候不要直接用消费端类消费产品，例如上面的是标准的不成熟编程方式，我们下面会介绍简单工厂模式对上面的需求进行实现。首先介绍简单工厂包含的角色：

• 抽象产品 ：定义了产品的规范，描述了产品的主要特性和功能。
• 具体产品 ：实现或者继承抽象产品的子类
• 具体工厂 ：提供了创建产品的方法，调用者通过该方法来获取产品。

现在使用简单工厂对上面案例进行改进，类图如下：

工厂类代码如下：

public class SimpleCoffeeFactory {
    // 这个类也可以定义为静态的，因为它相当于是一个工具类用于产生咖啡对象
    public Coffee createCoffee(String type) {
        Coffee coffee = null;
        if("americano".equals(type)) {
            coffee = new AmericanoCoffee();
        } else if("latte".equals(type)) {
            coffee = new LatteCoffee();
        }
        return coffee;
    }
}

工厂（factory）处理创建对象的细节，一旦有了SimpleCoffeeFactory，CoffeeStore类中的orderCoffee()就变成此对象的客户，后期如果需要Coffee对象直接从工厂中获取即可。这样也就解除了和Coffee实现类的耦合，同时又产生了新的耦合，CoffeeStore对象和SimpleCoffeeFactory工厂对象的耦合，工厂对象和商品对象的耦合。后期如果再加新品种的咖啡，我们势必要需求修改SimpleCoffeeFactory的代码，违反了开闭原则。工厂类的客户端可能有很多，比如创建美团外卖等，这样只需要修改工厂类的代码，省去其他的修改操作。

优点：

封装了创建对象的过程，可以通过参数直接获取对象。把对象的创建和业务逻辑层分开，这样以后就避免了修改客户代码，如果要实现新产品直接修改工厂类，而不需要在原代码中修改，这样就降低了客户代码修改的可能性，更加容易扩展。

缺点：

增加新产品时还是需要修改工厂类的代码，违背了“开闭原则”。

工厂方法模式

工厂方法模式是来解决简单工厂方法模式的缺点的，使用工厂方法模式就可以完美的解决，完全遵循开闭原则。工厂方法模式的核心思路就是：每种产品对应自己的工厂类，客户类与工厂类建立联系！注意，简单工厂模式是一个工厂生产多种产品，而工厂方法模式是一个工厂生产一种产品。其包含的角色：

• 抽象工厂（Abstract Factory）：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法来创建产品。
• 具体工厂（ConcreteFactory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
• 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能。
• 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。

使用工厂方法模式对上例进行改进，类图如下：

为什么解决了开闭原则？因为开闭原则讲的是开放扩展，闭合修改。也就是说新需求来了应该扩展而不是去修改旧的代码，而我们上面的设计模式如果来了一个新的卡布奇诺咖啡，不需要修改工厂类和消费端CoffeeStore的代码了。只需要增加卡布奇诺咖啡对象和对应的工厂，然后将卡布奇诺工厂作为参数传给客户端通过工厂类创建产品！工厂方法模式是简单工厂模式的进一步抽象。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。关键代码如下：

抽象工厂：

public interface CoffeeFactory {
    Coffee createCoffee();
}

具体工厂：

public class LatteCoffeeFactory implements CoffeeFactory {

    public Coffee createCoffee() {
        return new LatteCoffee();
    }
}

public class AmericanCoffeeFactory implements CoffeeFactory {

    public Coffee createCoffee() {
        return new AmericanCoffee();
    }
}

咖啡店类：

public class CoffeeStore {

    private CoffeeFactory factory;

    public CoffeeStore(CoffeeFactory factory) {
        this.factory = factory;
    }

    public Coffee orderCoffee() {
        Coffee coffee = factory.createCoffee();
        coffee.addMilk();
        coffee.addsugar();
        return coffee;
    }
}

优点：

• 用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程；
• 在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类，无须对原工厂进行任何修改，满足开闭原则；

缺点：

• 每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，这增加了系统的复杂度。

抽象工厂方法模式

抽象工厂方法更加难一点，但是千万要结合工厂方法模式来理解，抽象工厂模式是工厂方法模式的升级版本，工厂方法模式一个工厂只生产一个种产品，而抽象工厂模式一个工厂可生产多个相同系列或者产品族的产品。举个例子，假设产品有如下：华为手机、Mac电脑、iPhone、华为电脑；如果叫你设计创建这些产品的创建类你会如何创建？下面介绍各种等级的程序员的做法：

• 初级程序员：创建手机抽象类和电脑抽象类，然后华为手机、iPhone继承手机抽象类进行实现，Mac电脑和华为电脑继承电脑抽象类进行实现。在消费类需要创建产品的时候直接通过实现类进行new创建。评价：参加期末考试可以，但是工作中不行，首先不要随便使用抽象类（使用接口替代），另外产品和使用的消费类直接耦合，如果产品变了或者增加产品，需要直接修改消费类代码，违背开闭原则。

• 中级程序员：使用工厂方法模式，类似上面那个咖啡店与咖啡工厂的图片例子，只不过多了个工厂，如下图所示。但是这样就两个产品族就如此乱了，如果再多几个小米手机、小米电脑、惠普电脑、华硕电脑等，那岂不是创建的类要爆炸了。

  

• 高级程序员：使用抽象工厂方法，抽象工厂方法不是为了用而用，目的不是为了秀技能而是来解决问题的。上面的这个设计不能说差，但是缺点也很明显，就是一个工厂一个产品，一旦产品多起来了就很复杂。抽象工厂方法是对工厂进行改造，因此要想好一个工厂需要负责生产哪些产品。例如，上述产品可以分为华为系和苹果系产品。这样华为工厂就能负责创建华为手机和华为电脑，而苹果工厂就能创建iPhone和Mac电脑。但是如果来了其他品牌，还是要创建新的工厂，但是只需要实现一个该品牌的工厂就行，不需要为该品牌每一个产品都创建一个对应的工厂。这就是抽象工厂模式，实际上不难！

  

抽象工厂模式的主要角色如下：

• 抽象工厂（Abstract Factory）：提供了创建产品的接口，它包含多个创建产品的方法，可以创建多个不同等级的产品。
• 具体工厂（Concrete Factory）：主要是实现抽象工厂中的多个抽象方法，完成具体产品的创建。
• 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能，抽象工厂模式有多个抽象产品。
• 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它 同具体工厂之间是多对一的关系。

咖啡实例

现咖啡店业务发生改变，不仅要生产咖啡还要生产甜点，如提拉米苏、抹茶慕斯等，要是按照工厂方法模式，需要定义提拉米苏类、抹茶慕斯类、提拉米苏工厂、抹茶慕斯工厂、甜点工厂类，很容易发生类爆炸情况。其中拿铁咖啡、美式咖啡是一个产品等级，都是咖啡；提拉米苏、抹茶慕斯也是一个产品等级；拿铁咖啡和提拉米苏是同一产品族（也就是都属于意大利风味），美式咖啡和抹茶慕斯是同一产品族（也就是都属于美式风味）。所以这个案例可以使用抽象工厂模式实现。类图如下：

优点：

当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。

缺点：

当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。

建造者模式

经典的建造者模式

终于到了简单的创建者模式了，建造者模式主要解决一个复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的表示。说人话就是一个对象可能很复杂，在实例化它之前需要先实例化大量所依赖的其他对象，例如实例化一台电脑需要实例化CPU、主板、电源、硬盘、键盘、显示器、内存条…等设备，那么这些复杂的部件东西全部交给一个叫做Builder对象来提供，它仅仅是提供所需的部件对象。而Director对象通过Builder提供的部件按照一定的顺序和逻辑将这些部件组装成一个电脑对象。实现了构建和装配的解耦。不同的构建器，相同的装配，也可以做出不同的对象；相同的构建器，不同的装配顺序也可以做出不同的对象。也就是实现了构建算法、装配算法的解耦，实现了更好的复用。建造者模式下程序员可以将部件和其组装过程分开，一步一步创建一个复杂的对象。程序员只需要指定复杂对象的类型就可以得到该对象，而无须知道其内部的具体构造细节。大大简化了创建复杂对象的过程！那么建造者（Builder）模式包含如下角色：

• 抽象建造者类（Builder）：这个接口规定要实现复杂对象的那些部分的创建，并不涉及具体的部件对象的创建。

• 具体建造者类（ConcreteBuilder）：实现 Builder 接口，完成复杂产品的各个部件的具体创建方法。在构造过程完成后，提供产品的实例。

• 产品类（Product）：要创建的复杂对象。

• 指挥者类（Director）：调用具体建造者来创建复杂对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建。

类图如下：

经过前面的工厂方法模式，你现在应该举一反三知道要写一个建造者就不能简单写一个具体的建造者，而是加一层先提供一个抽象建造者！下面通过实例来理解。

创建共享单车

生产自行车是一个复杂的过程，它包含了车架，车座等组件的生产。而车架又有碳纤维，铝合金等材质的，车座有橡胶，真皮等材质。对于自行车的生产就可以使用建造者模式。这里Bike是产品，包含车架，车座等组件；Builder是抽象建造者，MobikeBuilder和OfoBuilder是具体的建造者；Director是指挥者。类图如下：

具体的代码如下：

//自行车类
public class Bike {
    private String frame;
    private String seat;

    public String getFrame() {
        return frame;
    }

    public void setFrame(String frame) {
        this.frame = frame;
    }

    public String getSeat() {
        return seat;
    }

    public void setSeat(String seat) {
        this.seat = seat;
    }
}

// 抽象 builder 类
public abstract class Builder {

    protected Bike mBike = new Bike();

    public abstract void buildFrame();
    public abstract void buildSeat();
    public abstract Bike createBike();
}

//摩拜单车Builder类
public class MobikeBuilder extends Builder {

    @Override
    public void buildFrame() {
        mBike.setFrame("铝合金车架");
    }

    @Override
    public void buildSeat() {
        mBike.setSeat("真皮车座");
    }

    @Override
    public Bike createBike() {
        return mBike;
    }
}

//ofo单车Builder类
public class OfoBuilder extends Builder {

    @Override
    public void buildFrame() {
        mBike.setFrame("碳纤维车架");
    }

    @Override
    public void buildSeat() {
        mBike.setSeat("橡胶车座");
    }

    @Override
    public Bike createBike() {
        return mBike;
    }
}

//指挥者类
public class Director {
    private Builder mBuilder;

    public Director(Builder builder) {
        mBuilder = builder;
    }

    public Bike construct() {
        mBuilder.buildFrame();
        mBuilder.buildSeat();
        return mBuilder.createBike();
    }
}

//测试类
public class Client {
    public static void main(String[] args) {
        showBike(new OfoBuilder());
        showBike(new MobikeBuilder());
    }
    private static void showBike(Builder builder) {
        Director director = new Director(builder);
        Bike bike = director.construct();
        System.out.println(bike.getFrame());
        System.out.println(bike.getSeat());
    }
}

注意：

上面示例是 Builder模式的常规用法，指挥者类 Director 在建造者模式中具有很重要的作用，它用于指导具体构建者如何构建产品，控制调用先后次序，并向调用者返回完整的产品类，但是有些情况下需要简化系统结构，可以把指挥者类和抽象建造者进行结合

// 抽象 builder 类
public abstract class Builder {
    protected Bike mBike = new Bike();
    
    public abstract void buildFrame();
    public abstract void buildSeat();
    public abstract Bike createBike();
    
    public Bike construct() {
        this.buildFrame();
        this.BuildSeat();
        return this.createBike();
    }
}

说明：

这样做确实简化了系统结构，但同时也加重了抽象建造者类的职责，也不是太符合单一职责原则，如果construct() 过于复杂，建议还是封装到 Director 中。

优点：

• 建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。
• 在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
• 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
• 建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。符合开闭原则。

缺点：

造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。

使用场景

建造者（Builder）模式创建的是复杂对象，其产品的各个部分经常面临着剧烈的变化，但将它们组合在一起的算法却相对稳定，所以它通常在以下场合使用。

• 创建的对象较复杂，由多个部件构成，各部件面临着复杂的变化，但构件间的建造顺序是稳定的。
• 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式，即产品的构建过程和最终的表示是独立的。

建造者模式的扩展

如果你使用过Lombok类库就知道它是典型的建造者模式，在开发中还有一个常用的使用方式，就是当一个类构造器需要传入很多参数时，如果创建这个类的实例，代码可读性会非常差，而且很容易引入错误，此时就可以利用建造者模式进行重构优化。

假设需要创建一个复杂的Phone对象，重构前代码如下：

public class Phone {
    private String cpu;
    private String screen;
    private String memory;
    private String mainboard;

    public Phone(String cpu, String screen, String memory, String mainboard) {
        this.cpu = cpu;
        this.screen = screen;
        this.memory = memory;
        this.mainboard = mainboard;
    }

    public String getCpu() {
        return cpu;
    }

    public void setCpu(String cpu) {
        this.cpu = cpu;
    }
    // 下面省略大量的 screen memory mainboard 的get和set方法
    // .......

    @Override
    public String toString() {
        return "Phone{" +
                "cpu='" + cpu + '\'' +
                ", screen='" + screen + '\'' +
                ", memory='" + memory + '\'' +
                ", mainboard='" + mainboard + '\'' +
                '}';
    }
}

public class Client {
    public static void main(String[] args) {
        //构建Phone对象
        Phone phone = new Phone("intel","三星屏幕","金士顿","华硕");
        System.out.println(phone);
    }
}

上面在客户端代码中构建Phone对象，传递了四个参数，如果参数更多呢？代码的可读性及使用的成本就是比较高。

重构后代码：

public class Phone {

    private String cpu;
    private String screen;
    private String memory;
    private String mainboard;
	
    // 还记得我们的Builder对象负责提供部件吗？也就是创建对象的参数！
    // 因此这里这需要Builder对象即可。
    private Phone(Builder builder) {
        cpu = builder.cpu;
        screen = builder.screen;
        memory = builder.memory;
        mainboard = builder.mainboard;
    }
	
    // 静态内部类
    public static final class Builder {
        private String cpu;
        private String screen;
        private String memory;
        private String mainboard;

        public Builder() {}

        public Builder cpu(String val) {
            cpu = val;
            return this;
        }
        public Builder screen(String val) {
            screen = val;
            return this;
        }
        public Builder memory(String val) {
            memory = val;
            return this;
        }
        public Builder mainboard(String val) {
            mainboard = val;
            return this;
        }
        public Phone build() {
            return new Phone(this);}
    }
    @Override
    public String toString() {
        return "Phone{" +
                "cpu='" + cpu + '\'' +
                ", screen='" + screen + '\'' +
                ", memory='" + memory + '\'' +
                ", mainboard='" + mainboard + '\'' +
                '}';
    }
}

public class Client {
    public static void main(String[] args) {
        Phone phone = new Phone.Builder() //这里创建的是Phone里面的Builder对象
                .cpu("intel") // 调用Builder对象里面的方法，并返回自身对象
                .mainboard("华硕")
                .memory("金士顿")
                .screen("三星")
                .build(); // 这里才是创建Phone对象，将Builder自己传入Phone对象创建
        System.out.println(phone);
    }
}

重构后的代码在使用起来更方便，某种程度上也可以提高开发效率。从软件设计上，对程序员的要求比较高。

原型模式

这个设计模式就是Java中的浅拷贝与深拷贝原理，Java中的Object类中提供了 clone() 方法来实现浅克隆。 Cloneable 接口是上面的类图中的抽象原型类，而实现了Cloneable接口的子实现类就是具体的原型类。如果一个类中没有引用成员变量，那么浅拷贝和深拷贝都是重新创建一个新的对象，即拷贝后的对象与被拷贝对象不是同一个；如果一个类中有引用成员变量，那么如果简单使用clone()浅拷贝那么新的对象还是会共用引用对象，这种情况需要使用深克隆，而进行深克隆需要使用对象流。原型模式不太常用，除非遇到以下情况：对象的创建非常复杂，可以使用原型模式快捷的创建对象。性能和安全要求比较高。

接口类图如下：

大总结

上面都是在思考如何合理地创建对象，不同场景有不同的解决方案，总体设计符合软件设计原则。这个总结很有必要，有利于工作中可以快速反应应该使用什么样的设计模式来解决问题，这就是高级程序员与其他程序员的区别！也是实力的体现！总结如下：

• 单例模式：单例应该是最简单的，单例使用的情景是全局只需要创建一个对象即可的场景，例如数据库连接池对象。建议使用枚举类、静态内部类方式创建单例，不建议双重检查创建单例（加锁）。
• 工厂方法模式：简单工厂模式应该是一种编程习惯（改进了消费类问工厂获取产品而不直接new产品对象，但不满足开闭原则，增加新产品需要修改工厂类），工厂方法模式是一个工厂负责一个产品，这样增加产品时只需要增加对应的工厂类和产品类而不是去修改旧代码。缺点是当产品太多时创建的工厂也就太多，增加系统负责度。
• 抽象工厂模式：对产品进行了分类，某个工厂负责创建同一系列或者产品族的多个产品，克服了工厂方法模式创建太多工厂的缺点。使用场景：

  • 当需要创建的对象是一系列相互关联或相互依赖的产品族时，如电器工厂中的电视机、洗衣机、空调等。

  • 系统中有多个产品族，但每次只使用其中的某一族产品。如有人只喜欢穿某一个品牌的衣服和鞋。

  • 系统中提供了产品的类库，且所有产品的接口相同，客户端不依赖产品实例的创建细节和内部结构。

• 原型模式：本质是对象的深度拷贝和浅拷贝，对象的创建非常复杂，可以使用原型模式快捷的创建对象，性能和安全要求比较高时使用。
• 建造者模式：创建某个对象时参数太多了，过于复杂时考虑使用。分离了部件的构造(由Builder来负责)和装配(由Director负责)。它的扩展模式非常有用，就是当一个类构造器需要传入很多参数时，如果创建这个类的实例，代码可读性会非常差，而且很容易引入错误，此时就可以利用建造者模式进行重构。

工厂方法模式与建造者模式的区别：

工厂方法模式注重的是整体对象的创建方式；而建造者模式注重的是一个对象的部件构建的过程，意在通过一步一步地精确构造创建出一个复杂的对象。工厂方法模式关注多个产品直接的关系，产品由工厂直接创建，不关心生产过程。而建造者模式是关注一个产品每一个部件的产生和组装。例如：如要制造一个超人，如果使用工厂方法模式，直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人；而如果使用建造者模式，则需要组装手、头、脚、躯干等部分，然后再把内裤外穿，于是一个超人就诞生了。而抽象工厂模式关注点是实现对产品家族的创建，一个产品家族是这样的一系列产品：具有不同分类维度的产品组合，采用抽象工厂模式则是不需要关心构建过程，只关心什么产品由什么工厂生产即可。