接上篇：23种设计模式全解析_00概述:设计模式的分类和设计原则

本篇内容：

A、创建模式（共5种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式）

从这一块开始，我们详细介绍Java中23种设计模式的概念，应用场景等情况，并结合他们的特点及设计模式的原则进行分析。

首先，简单工厂模式不属于23种设计模式，简单工厂一般分为：普通简单工厂、多方法简单工厂、静态方法简单工厂。

0、简单工厂模式

简单工厂模式模式分为三种：

01、普通

就是建立一个工厂类，对实现了同一接口的一些类进行实例的创建。首先看下关系图：

举例如下：（我们举一个发送邮件和短信的例子）

首先，创建二者的共同接口：

public interface Sender { public void Send();}

其次，创建实现类：

public class MailSender implements Sender { @Override public void Send() { System.out.println("this is mailsender!"); }}public class SmsSender implements Sender {  @Override public void Send() { System.out.println("this is sms sender!"); }}

最后，建工厂类：

public class SendFactory { public Sender produce(String type) { if ("mail".equals(type)) { return new MailSender(); } else if ("sms".equals(type)) { return new SmsSender(); } else { System.out.println("请输入正确的类型!"); return null; } } }

我们来测试下：

public class FactoryTest { public static void main(String[] args) { SendFactory factory = new SendFactory(); Sender sender = factory.produce("sms"); sender.Send(); }}

输出：this is sms sender!

02、多个方法

是对普通工厂方法模式的改进，在普通工厂方法模式中，如果传递的字符串出错，则不能正确创建对象，而多个工厂方法模式是提供多个工厂方法，分别创建对象。关系图：

将上面的代码做下修改，改动下SendFactory类就行，如下：

public class SendFactory { public Sender produceMail(){ return new MailSender(); } public Sender produceSms(){ return new SmsSender(); }}

测试类如下：

public class FactoryTest {  public static void main(String[] args) {  SendFactory factory = new SendFactory();  Sender sender = factory.produceMail();  sender.Send();  } }

输出：this is mailsender!

03、多个静态方法

将上面的多个工厂方法模式里的方法置为静态的，不需要创建实例，直接调用即可。

public class SendFactory { public static Sender produceMail(){  return new MailSender();  }   public static Sender produceSms(){  return new SmsSender();  } }  public class FactoryTest {  public static void main(String[] args) { Sender sender = SendFactory.produceMail(); sender.Send();  } }  

输出：this is mailsender!

总体来说，工厂模式适合：凡是出现了大量的产品需要创建，并且具有共同的接口时，可以通过工厂方法模式进行创建。在以上的三种模式中，第一种如果传入的字符串有误，不能正确创建对象，第三种相对于第二种，不需要实例化工厂类，所以，大多数情况下，我们会选用第三种——静态工厂方法模式。

1、工厂方法模式（Factory Method）

简单工厂模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，如何解决？就用到工厂方法模式，创建一个工厂接口和创建多个工厂实现类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。

请看例子：

public interface Sender {  public void Send(); } 

两个实现类：

public class MailSender implements Sender {

@Override

public void Send() {

System.out.println("this is mailsender!");

}

}

public class SmsSender implements Sender {

@Override

public void Send() {

System.out.println("this is sms sender!");

}

}

两个工厂类：

public class SendMailFactory implements Provider {   @Override  public Sender produce(){  return new MailSender();  } }public class SendSmsFactory implements Provider{   @Override  public Sender produce() {  return new SmsSender();  } } 

再提供一个接口：

public interface Provider {  public Sender produce(); } 

测试类：

public class Test {   public static void main(String[] args) {  Provider provider = new SendMailFactory();  Sender sender = provider.produce();  sender.Send();  } } 

其实这个模式的好处就是，如果你现在想增加一个功能：发及时信息，则只需做一个实现类，实现Sender接口，同时做一个工厂类，实现Provider接口，就OK了，无需去改动现成的代码。这样做，拓展性较好！

2、抽象工厂模式

工厂方法模式和抽象工厂模式不好分清楚，他们的区别如下：

工厂方法模式：

一个抽象产品类，可以派生出多个具体产品类。

一个抽象工厂类，可以派生出多个具体工厂类。

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

抽象工厂模式：

多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。

一个抽象工厂类，可以派生出多个具体工厂类。

每个具体工厂类可以创建多个具体产品类的实例，也就是创建的是一个产品线下的多个产品。

区别：

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

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

工厂方法创建 "一种" 产品，他的着重点在于"怎么创建"，也就是说如果你开发，你的大量代码很可能围绕着这种产品的构造，初始化这些细节上面。也因为如此，类似的产品之间有很多可以复用的特征，所以会和模版方法相随。

抽象工厂需要创建一些列产品，着重点在于"创建哪些"产品上，也就是说，如果你开发，你的主要任务是划分不同差异的产品线，并且尽量保持每条产品线接口一致，从而可以从同一个抽象工厂继承。

对于java来说，你能见到的大部分抽象工厂模式都是这样的：

---它的里面是一堆工厂方法，每个工厂方法返回某种类型的对象。

比如说工厂可以生产鼠标和键盘。那么抽象工厂的实现类（它的某个具体子类）的对象都可以生产鼠标和键盘，但可能工厂A生产的是罗技的键盘和鼠标，工厂B是微软的。

这样A和B就是工厂，对应于抽象工厂；

每个工厂生产的鼠标和键盘就是产品，对应于工厂方法；

用了工厂方法模式，你替换生成键盘的工厂方法，就可以把键盘从罗技换到微软。但是用了抽象工厂模式，你只要换家工厂，就可以同时替换鼠标和键盘一套。如果你要的产品有几十个，当然用抽象工厂模式一次替换全部最方便（这个工厂会替你用相应的工厂方法）

所以说抽象工厂就像工厂，而工厂方法则像是工厂的一种产品生产线

3、单例模式（Singleton）

单例对象（Singleton）是一种常用的设计模式。在Java应用中，单例对象能保证在一个JVM中，该对象只有一个实例存在。这样的模式有几个好处：

1、某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。

2、省去了new操作符，降低了系统内存的使用频率，减轻GC压力。

3、有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。（比如一个军队出现了多个司令员同时指挥，肯定会乱成一团），所以只有使用单例模式，才能保证核心交易服务器独立控制整个流程。

首先我们写一个简单的单例类：

public class Singleton {   /* 持有私有静态实例，防止被引用，此处赋值为null，目的是实现延迟加载 */  private static Singleton instance = null;   /* 私有构造方法，防止被实例化 */  private Singleton() {  }   /* 静态工程方法，创建实例 */  public static Singleton getInstance() {  if (instance == null) {  instance = new Singleton();  }  return instance;  }   /* 如果该对象被用于序列化，可以保证对象在序列化前后保持一致 */  public Object readResolve() {  return instance;  } } 

这个类可以满足基本要求，但是，像这样毫无线程安全保护的类，如果我们把它放入多线程的环境下，肯定就会出现问题了，如何解决？我们首先会想到对getInstance方法加synchronized关键字，如下：

public static synchronized Singleton getInstance() {

if (instance == null) {

instance = new Singleton();

}

return instance;

}

但是，synchronized关键字锁住的是这个对象，这样的用法，在性能上会有所下降，因为每次调用getInstance()，都要对对象上锁，事实上，只有在第一次创建对象的时候需要加锁，之后就不需要了，所以，这个地方需要改进。我们改成下面这个：

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

似乎解决了之前提到的问题，将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实例，却发现它没有被初始化，于是错误发生了。

所以程序还是有可能发生错误，其实程序在运行过程是很复杂的，从这点我们就可以看出，尤其是在写多线程环境下的程序更有难度，有挑战性。我们对该程序做进一步优化：

private static class SingletonFactory{  private static Singleton instance = new Singleton();  }  public static Singleton getInstance(){  return SingletonFactory.instance;  } 

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

public class Singleton {

/* 私有构造方法，防止被实例化 */

private Singleton() {

}

/* 此处使用一个内部类来维护单例 */

private static class SingletonFactory {

private static Singleton instance = new Singleton();

}

/* 获取实例 */

public static Singleton getInstance() {

return SingletonFactory.instance;

}

/* 如果该对象被用于序列化，可以保证对象在序列化前后保持一致 */

public Object readResolve() {

return getInstance();

}

}

其实说它完美，也不一定，如果在构造函数中抛出异常，实例将永远得不到创建，也会出错。所以说，十分完美的东西是没有的，我们只能根据实际情况，选择最适合自己应用场景的实现方法。也有人这样实现：因为我们只需要在创建类的时候进行同步，所以只要将创建和getInstance()分开，单独为创建加synchronized关键字，也是可以的：

public class SingletonTest {   private static SingletonTest instance = null;   private SingletonTest() {  }   private static synchronized void syncInit() {  if (instance == null) {  instance = new SingletonTest();  }  }   public static SingletonTest getInstance() {  if (instance == null) {  syncInit();  }  return instance;  } } 

考虑性能的话，整个程序只需创建一次实例，所以性能也不会有什么影响。

采用"影子实例"的办法为单例对象的属性同步更新

public class SingletonTest {   private static SingletonTest instance = null;  private Vector properties = null;   public Vector getProperties() {  return properties;  }   private SingletonTest() {  }   private static synchronized void syncInit() {  if (instance == null) {  instance = new SingletonTest();  }  }   public static SingletonTest getInstance() {  if (instance == null) {  syncInit();  }  return instance;  }   public void updateProperties() {  SingletonTest shadow = new SingletonTest();  properties = shadow.getProperties();  } } 

通过单例模式的学习告诉我们：

1、单例模式理解起来简单，但是具体实现起来还是有一定的难度。

2、synchronized关键字锁定的是对象，在用的时候，一定要在恰当的地方使用（注意需要使用锁的对象和过程，可能有的时候并不是整个对象及整个过程都需要锁）。

到这儿，单例模式基本已经讲完了，结尾处，笔者突然想到另一个问题，就是采用类的静态方法，实现单例模式的效果，也是可行的，此处二者有什么不同？

首先，静态类不能实现接口。（从类的角度说是可以的，但是那样就破坏了静态了。因为接口中不允许有static修饰的方法，所以即使实现了也是非静态的）

其次，单例可以被延迟初始化，静态类一般在第一次加载是初始化。之所以延迟加载，是因为有些类比较庞大，所以延迟加载有助于提升性能。

再次，单例类可以被继承，他的方法可以被覆写。但是静态类内部方法都是static，无法被覆写。

最后一点，单例类比较灵活，毕竟从实现上只是一个普通的Java类，只要满足单例的基本需求，你可以在里面随心所欲的实现一些其它功能，但是静态类不行。从上面这些概括中，基本可以看出二者的区别，但是，从另一方面讲，我们上面最后实现的那个单例模式，内部就是用一个静态类来实现的，所以，二者有很大的关联，只是我们考虑问题的层面不同罢了。两种思想的结合，才能造就出完美的解决方案，就像HashMap采用数组+链表来实现一样，其实生活中很多事情都是这样，单用不同的方法来处理问题，总是有优点也有缺点，最完美的方法是，结合各个方法的优点，才能最好的解决问题！

4、建造者模式（Builder）

建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。

介绍

意图：将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。

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

何时使用：一些基本部件不会变，而其组合经常变化的时候。

如何解决：将变与不变分离开。

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

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

优点： 1、建造者独立，易扩展。 2、便于控制细节风险。

缺点： 1、产品必须有共同点，范围有限制。 2、如内部变化复杂，会有很多的建造类。

使用场景： 1、需要生成的对象具有复杂的内部结构。 2、需要生成的对象内部属性本身相互依赖。

注意事项：与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。

实现

我们假设一个快餐店的商业案例，其中，一个典型的套餐可以是一个汉堡（Burger）和一杯冷饮（Cold drink）。汉堡（Burger）可以是素食汉堡（Veg Burger）或鸡肉汉堡（Chicken Burger），它们是包在纸盒中。冷饮（Cold drink）可以是可口可乐（coke）或百事可乐（pepsi），它们是装在瓶子中。

我们将创建一个表示食物条目（比如汉堡和冷饮）的 Item 接口和实现 Item 接口的实体类，以及一个表示食物包装的 Packing 接口和实现 Packing接口的实体类，汉堡是包在纸盒中，冷饮是装在瓶子中。

然后我们创建一个 Meal 类，带有 Item 的 ArrayList 和一个通过结合 Item 来创建不同类型的 Meal 对象的 MealBuilder。BuilderPatternDemo，我们的演示类使用 MealBuilder 来创建一个 Meal。

步骤 1

创建一个表示食物条目和食物包装的接口。

Item.java

public interface Item { public String name(); public Packing packing(); public float price(); }

Packing.java

public interface Packing { public String pack();}

步骤 2

创建实现 Packing 接口的实体类。

Wrapper.java

public class Wrapper implements Packing {  @Override public String pack() { return "Wrapper"; }}

Bottle.java

public class Bottle implements Packing {  @Override public String pack() { return "Bottle"; }}

步骤 3

创建实现 Item 接口的抽象类，该类提供了默认的功能。

Burger.java

public abstract class Burger implements Item {  @Override public Packing packing() { return new Wrapper(); }  @Override public abstract float price();}

ColdDrink.java

public abstract class ColdDrink implements Item {  @Override public Packing packing() { return new Bottle(); }  @Override public abstract float price();}

步骤 4

创建扩展了 Burger 和 ColdDrink 的实体类。

VegBurger.java

public class VegBurger extends Burger {  @Override public float price() { return 25.0f; }  @Override public String name() { return "Veg Burger"; }}

ChickenBurger.java

public class ChickenBurger extends Burger {  @Override public float price() { return 50.5f; }  @Override public String name() { return "Chicken Burger"; }}

Coke.java

public class Coke extends ColdDrink {  @Override public float price() { return 30.0f; }  @Override public String name() { return "Coke"; }}

Pepsi.java

public class Pepsi extends ColdDrink {  @Override public float price() { return 35.0f; }  @Override public String name() { return "Pepsi"; }}

步骤 5

创建一个 Meal 类，带有上面定义的 Item 对象。

Meal.java

import java.util.ArrayList;import java.util.List; public class Meal { private List<Item> items = new ArrayList<Item>();   public void addItem(Item item){ items.add(item); }  public float getCost(){ float cost = 0.0f; for (Item item : items) { cost += item.price(); }  return cost; }  public void showItems(){ for (Item item : items) { System.out.print("Item : "+item.name()); System.out.print(", Packing : "+item.packing().pack()); System.out.println(", Price : "+item.price()); }  } }

步骤 6

创建一个 MealBuilder 类，实际的 builder 类负责创建 Meal 对象。

MealBuilder.java

public class MealBuilder {  public Meal prepareVegMeal (){ Meal meal = new Meal(); meal.addItem(new VegBurger()); meal.addItem(new Coke()); return meal; }   public Meal prepareNonVegMeal (){ Meal meal = new Meal(); meal.addItem(new ChickenBurger()); meal.addItem(new Pepsi()); return meal; }}

步骤 7

BuiderPatternDemo 使用 MealBuider 来演示建造者模式（Builder Pattern）。

BuilderPatternDemo.java

public class BuilderPatternDemo { public static void main(String[] args) { MealBuilder mealBuilder = new MealBuilder();  Meal vegMeal = mealBuilder.prepareVegMeal(); System.out.println("Veg Meal"); vegMeal.showItems(); System.out.println("Total Cost: " +vegMeal.getCost());  Meal nonVegMeal = mealBuilder.prepareNonVegMeal(); System.out.println("\n\nNon-Veg Meal"); nonVegMeal.showItems(); System.out.println("Total Cost: " +nonVegMeal.getCost()); }}

步骤 8

执行程序，输出结果：

Veg MealItem : Veg Burger, Packing : Wrapper, Price : 25.0Item : Coke, Packing : Bottle, Price : 30.0Total Cost: 55.0Non-Veg MealItem : Chicken Burger, Packing : Wrapper, Price : 50.5Item : Pepsi, Packing : Bottle, Price : 35.0Total Cost: 85.5

建造者模式举例：

去肯德基点餐，我们可以认为点餐就属于一个建造订单的过程。我们点餐的顺序是无关的，点什么东西也是没有要求的，可以单点，也可以点套餐，也可以套餐加单点，但是最后一定要点确认来完成订单。

public class OrderBuilder{

private Burger mBurger;

private Suit mSuit;

//单点汉堡,num为数量

public OrderBuilder burger(Burger burger， int num){

mBurger = burger;

}

//点套餐，实际中套餐也可以点多份

public OrderBuilder suit(Suit suit, int num){

mSuit = suit;

}

//完成订单

public Order build(){

Order order = new Order();

order.setBurger(mBurger);

order.setSuit(mSuit);

return order;

}

}

另外适用于快速失败，在 build 时可以做校验，如果不满足必要条件，则可以直接抛出创建异常，在 OkHttp3 中的 Request.Builder 中就是这样用的。

public Request build() {  if (url == null) throw new IllegalStateException("url == null");  return new Request(this);}

例如订单要求价格至少达到 30 块:

//完成订单public Order build(){ Order order = new Order(); order.setBurger(mBurger); order.setSuit(mSuit); if(order.getPrice() < 30){ throw new BuildException("订单金额未达到30元"); } return order;}

另外，在构建时如果有必传参数和可选参数，可以为 Builder 类添加构造函数来保证必传参数不会遗漏，例如在构建一个 http 请求时, url 是必传的:

public class RequestBuilder{ private final String mUrl; private Map<String, String> mHeaders = new HashMap<String, String>(); private RequestBuilder(String url){ mUrl = url; } public static RequestBuilder newBuilder(String url){ return new RequestBuilder(url); } public RequestBuilder addHeader(String key, String value){ mHeaders.put(key, value); } public Request build(){ Request request = new Request(); request.setUrl(mUrl); request.setHeaders(mHeaders); return request; }}

5、原型模式（Prototype）

原型模式虽然是创建型的模式，但是与工程模式没有关系，从名字即可看出，该模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。本小结会通过对象的复制，进行讲解。在Java中，复制对象是通过clone()实现的，先创建一个原型类：

public class Prototype implements Cloneable {   public Object clone() throws CloneNotSupportedException {  Prototype proto = (Prototype) super.clone();  return proto;  } } 

很简单，一个原型类，只需要实现Cloneable接口，覆写clone方法，此处clone方法可以改成任意的名称，因为Cloneable接口是个空接口，你可以任意定义实现类的方法名，如cloneA或者cloneB，因为此处的重点是super.clone()这句话，super.clone()调用的是Object的clone()方法，而在Object类中，clone()是native的，具体怎么实现，我会在另一篇文章中，关于解读Java中本地方法的调用，此处不再深究。在这儿，我将结合对象的浅复制和深复制来说一下，首先需要了解对象深、浅复制的概念：

浅复制：将一个对象复制后，基本数据类型的变量都会重新创建，而引用类型，指向的还是原对象所指向的。

深复制：将一个对象复制后，不论是基本数据类型还有引用类型，都是重新创建的。简单来说，就是深复制进行了完全彻底的复制，而浅复制不彻底。

此处，写一个深浅复制的例子：

public class Prototype implements Cloneable, Serializable {   private static final long serialVersionUID = 1L;  private String string;   private SerializableObject obj;   /* 浅复制 */  public Object clone() throws CloneNotSupportedException {  Prototype proto = (Prototype) super.clone();  return proto;  }   /* 深复制 */  public Object deepClone() throws IOException, ClassNotFoundException {   /* 写入当前对象的二进制流 */  ByteArrayOutputStream bos = new ByteArrayOutputStream();  ObjectOutputStream oos = new ObjectOutputStream(bos);  oos.writeObject(this);   /* 读出二进制流产生的新对象 */  ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());  ObjectInputStream ois = new ObjectInputStream(bis);  return ois.readObject();  }   public String getString() {  return string;  }   public void setString(String string) {  this.string = string;  }   public SerializableObject getObj() {  return obj;  }   public void setObj(SerializableObject obj) {  this.obj = obj;  }  }  class SerializableObject implements Serializable {  private static final long serialVersionUID = 1L; } 

要实现深复制，需要采用流的形式读入当前对象的二进制输入，再写出二进制数据对应的对象。

下一篇介绍Java的23种设计模式之二结构模式（共7种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式）。