百日筑基第二十三天-23种设计模式-创建型总汇
前言
设计模式可以说是对于七大设计原则的实现。
总体来说设计模式分为三大类：
- 创建型模式，共五种：单例模式、简单工厂模式、抽象工厂模式、建造者模式、原型模式。
- 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
- 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
23种设计模式的关系图：
单例模式
简介
单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建（私有的构造器），这个类对外提供了唯一一种访问其实例的方式，对外只能够直接访问，不能实例化此类对象。例如，一台计算机上可以连接多台打印机，但是这个计算机上的打印程序只能有一个，这里就可以通过单例模式来避免两个打印作业同时输出到打印机中，即在整个的打印过程中只有一个打印程序的实例。
简单点说，单例模式（也叫单件模式）的作用就是保证在整个应用程序的生命周期中，任何时刻，单例类的实例都最多只存在一个。单例模式确保某一个类只有一个实例，而且自行实例化，并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”需求时才可以使用。
单例的类图如下：其中 uniqueInstance 持有唯一的单例实例，类方法 getInstance() 用来获取唯一的实例化对象。
Singleton —————————————————————— -static uniqueInstance -other Attribute —————————————————————— +static genInstance()() +otherMethods()
8 种单例实现方式（有点多但有必要都看）
【1】饿汉式（静态常量）优缺点：
● 优点：这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。没有加锁，执行效率会提高。
● 缺点：在类装载的时候就完成实例化，没有达到 Lazy Loading 的效果。如果从始至终从未使用过这个实例，则会造成内存浪费，容易产生垃圾对象。
● 这种方式基于 classload 机制避免了多线程同步问题，instance 在类装载时就实例化，在单例模式中大多数都是调用 getInstance 方法，但是导致类装载的原因有很多种，因此通过其他方式（或者其他静态方法）导致类装载，此时初始化 instance就没有达到 Lazy Loading 的效果。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//创建好一个私有的 SingleTon 实例
private static SingleTon instance = new SingleTon();
//提供一个 public 的静态方法, 可以返回 instance
public static SingleTon getInstance() {
return instance;
}
}
【2】饿汉式（静态代码块）优缺点：
● 这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面一样。
● 结论：这种单例模式可用，但可能造成内存浪费。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//创建好一个私有的 SingleTon 实例
private static SingleTon instance;
//静态块
static {
instance = new SingleTon();
}
//提供一个 public 的静态方法, 可以返回 instance
public static SingleTon getInstance() {
return instance;
}
}
【3】懒汉式（线程不安全）优缺点：
● 起到了 Lazy Loading 的效果，但是只能在单线程下使用。
● 如果在多线程下，一个线程进入if(singleton == null)判断语句块，还未来得及创建，另一个线程也通过了上述判断语句，这时便产生了多个实例。所以在多线程环境下不可使用这种方式。
● 结论：在实际开发中，不要使用这种方法。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//创建好一个私有的 SingleTon 实例
private static SingleTon instance;
//提供一个 public 的静态方法, 可以返回 instance
public static SingleTon getInstance() {
if(instance == null) {
instance = new SingleTon();
}
return instance;
}
}
【4】懒汉式（线程安全，同步方法）优缺点：
● 解决了线程不安全问题。
● 效率太低了，每个线程在想获得类的实例的时候，执行 getInstance() 方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得实例，直接 return 就够了。方法进行同步效率太低。
● 结论：在实际开发中不推荐使用。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//创建好一个私有的 SingleTon 实例
private static SingleTon instance;
//提供一个 public 的静态方法, 可以返回 instance
public static synchronized SingleTon getInstance() {
if(instance == null) {
instance = new SingleTon();
}
return instance;
}
}
【5】懒汉式（线程安全，同步代码块）优缺点：
● 这种方式，本意是想对第四种实现方式的改进，因为前面同步方法效率太低， 改为同步产生实例化的的代码块。
● 但是这种同步并不能起到线程同步的作用。跟第3种实现方式遇到的情形一致，假如一个线程进入了 if (singleton == null) 判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。
● 结论：在实际开发中，不能使用这种方式。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//创建好一个私有的 SingleTon 实例
private static SingleTon instance;
//提供一个 public 的静态方法, 可以返回 instance
public static SingleTon getInstance() {
if(instance == null) {
//添加同步代码块，提高了效率，多线程时存在创建的对象不一致风险
synchronized(SingleTon.class) {
instance = new SingleTon();
}
}
return instance;
}
}
【7】静态内部类优缺点：
● 这种方式采用了类加载器的机制来保证初始化实例时只有一个线程。
● 静态内部类方式在 SingleTon 类（父类）被装载时，不会导致内部类被装载，也就不会立即实例化，属于懒加载类型。当调用 getInstance() 方法时，才会装载 SingleTonInstance 类，从而完成 SingleTon 的实例化。
● 类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM 帮我们保证了线程的安全，在类初始化时，别的线程无法进入。
● 避免了线程不安全，利用静态内部类特点实现延迟加载，效率高。
● 结论：推荐使用。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//在内部内中创建一个对象的实例,当父类 SingleTon 加载时，内部类 SingleTonInstance 无需加载
private static class SingleTonInstance{
private static final SingleTon INSTANCE = new SingleTon();
}
//提供一个 public 的静态方法, 可以返回 SingleTon实例
public static SingleTon getInstance() {
return SingleTonInstance.INSTANCE;
}
}
【8】枚举优缺点：
● 这借助JDK1.5中添加的枚举来实现单例模式。不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。
● 这种方式是Effective Java作者Josh Bloch 提倡的方式
● 结论：推荐使用
enum SingleTon {
//当只有一个对象时,就是单例
INSTANCE;
}
单例模式注意事项和使用场景
【1】单例模式保证了系统内存中该内只存在一个对象，节省了系统资源，对于一些需要频繁创建和销毁的对象，使用单例模式可以提高系统性能。
【2】当想实例化一个单例类的时候，必须要记住使用相应的获取对象的方法，而不是使用 new。
【3】单例模式使用场景：
- 需要频繁的进行创建和销毁对象
- 创建对象时耗时过多或消耗过多资源（既重量级对象）但又常使用的对象
- 工具类对象
- 频繁访问数据库或文件的对象（比如数据源、session工厂等）
工厂模式
简介
工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单使用的模式。简单工厂模式定义了一个创建对象的类，由这个类来封装实例化对象的行为。在软件开发中，当我们会用到大量的创建某种、某类或者某批量对象时，就会使用到工厂模式。
简单工厂模式案例
【1】定义一个接口 Pizza
package com.yintong.principle.singleresponsibility;
//将Pizza 做成一个接口
public interface Pizza {
//准备原材料, 不同的披萨不一样，因此，我们做成抽象方法
public void prepare();
}
【2】定义披萨的种类，实现 Pizza 接口，如下定义了 GREEK、CHEESE 两种披萨。如果后续有新的种类可以实现 Pizza 接口，继续添加新的品种。
//希腊披萨
public class GreekPizza implements Pizza{
@Override
public void prepare() {
System.out.println(" 给希腊披萨 准备原材料 ");
}
}
//奶酪披萨
public class CheesePizza implements Pizza{
@Override
public void prepare() {
System.out.println(" 给制作奶酪披萨 准备原材料 ");
}
}
【3】 创建一个简单的工厂类对象 SimpleFactory
public class SimpleFactory {
//传入 orderType（种类） 返回对应的 Pizza 对象
public Pizza createPizza(String orderType) {
Pizza pizza = null;
//使用简单工厂模式
if (orderType.equals("greek")) {
//希腊披萨
pizza = new GreekPizza();
} else if (orderType.equals("cheese")) {
//奶酪披萨
pizza = new CheesePizza();
}
return pizza;
}
}
【4】在应用代码 OrderPizza 中调用工厂类，获取用户需要的披萨对象。
public class OrderPizza {
//定义用户要获取的披萨类型
private static final String pizza = "greek";
public static void main(String[] args) {
//通过工厂获取希腊披萨
SimpleFactory simpleFactory = new SimpleFactory();
//greekPizza 就是我们需要获取的目标披萨
Pizza greekPizza = simpleFactory.createPizza(pizza);
//调用目标披萨的方法
greekPizza.prepare();
}
}
简单工厂模式的优缺点
优点：
1）一个调用者想创建一个对象，只要知道其名称就可以了。
2）扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。
3）屏蔽产品的具体实现，调用者只关心产品接口。
缺点： 每增加一个产品时，都需要增加一个具体实现类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。
注意事项： 作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别只需要通过 new 就可以完成创建的对象，无需工厂模式。如果使用工厂模式就需要使用工厂类，会增加系统的复杂度。
抽象工厂方法模式
需求： 在上述的基础上，添加了地区。例如：用户可以点北京的奶酪披萨，北京的胡椒披萨，或者伦敦的奶酪披萨，伦敦的胡椒披萨。
工厂方法设计模式：
1）、定义一个 interface（工厂的接口） 用于创建相关或者依赖关系的对象簇，而无需指明具体对象类。
2）、从设计层面来看，抽象工厂模式就是简单工厂模式的改进（或者称为进一步抽象）。
3）、将工厂抽象成两层，AbsFactory（抽象工厂）和具体实现的工厂子类。程序员可以根据创建对象类型使用对应的工厂子类。这样将单个的简单工厂类变成了工厂簇，更有利于代码的维护和扩展。
类图： 将简单工厂模式中的工厂类抽象成了一个接口，易于后期扩展。
【1】定义工厂类的接口（AbsFactory）
//一个抽象工厂模式的抽象层(接口)
public interface AbsFactory {
//让下面的工厂子类来 具体实现
public Pizza createPizza(String orderType);
}
【2】让北京和伦敦的工厂类实现此接口（与简单工厂类的区别就是实现了 AbsFactory 接口，伦敦略）
public class BJFactory implements AbsFactory{
//更加orderType 返回对应的Pizza 对象
public Pizza createPizza(String orderType) {
Pizza pizza = null;
//使用简单工厂模式
if (orderType.equals("greek")) {
//希腊披萨
pizza = new GreekPizza();
} else if (orderType.equals("cheese")) {
//奶酪披萨
pizza = new CheesePizza();
}
return pizza;
}
}
【3】在 Order 订单应用中，与接口 AbsFactory 进行组合。
public class OrderPizza {
AbsFactory factory;
//定义构造器
public OrderPizza(AbsFactory factory){
this.factory = factory;
}
//定义用户要获取的披萨类型，可以定义一个变量从客户端传入
private static final String pizza = "greek";
public void main(String[] args) {
//greekPizza 就是我们需要获取的目标披萨
Pizza greekPizza = factory.createPizza(pizza);
//调用目标披萨的方法
greekPizza.prepare();
}
}
工厂模式在 JDK-Calendar 类中的应用
//1、调用 Calendar 对象
Calendar instance = Calendar.getInstance();
//2、进入 Calendar.getInstance() 方法
public static Calendar getInstance()
{
return createCalendar(TimeZone.getDefault(),Locale.getDefault(Locale.Category.FORMAT));
}
//3、进入 createCalendar 方法
private static Calendar createCalendar(TimeZone zone,Locale aLocale){
CalendarProvider provider =
LocaleProviderAdapter.getAdapter(CalendarProvider.class, aLocale)
.getCalendarProvider();
if (provider != null) {
try {
return provider.getInstance(zone, aLocale);
} catch (IllegalArgumentException iae) {
// fall back to the default instantiation
}
}
Calendar cal = null;
if (aLocale.hasExtensions()) {
String caltype = aLocale.getUnicodeLocaleType("ca");
if (caltype != null) {
//这里就是我们要重点查看的部分，根据用户需求，创建Calendar 对象
switch (caltype) {
case "buddhist":
cal = new BuddhistCalendar(zone, aLocale);
break;
case "japanese":
cal = new JapaneseImperialCalendar(zone, aLocale);
break;
case "gregory":
cal = new GregorianCalendar(zone, aLocale);
break;
}
}
}
return cal;
}
工厂模式小结
1）工厂模式的意义： 将实例化对象的代码提取出来，放到一个类中统一管理和维护，达到和主项目的依赖关系的解耦。从而提高项目的扩展和维护性。
2）设计模式依赖抽象原则： 创建对象实例时，不要直接 new 类，而是把这个 new 类的动作放在一个工厂的方法中，并返回。不要让类继承具体类，而是继承抽象类或者实现 interface（接口）。不要覆盖基类中已经实现的方法。
建造者模式
简介
建造者模式（Builder Pattern）： 使用简单的对象一步一步构建成一个复杂的对象。这种设计模式属于创建者模式，它提供了一种创建对象的最佳方式。一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。例如，计算机是由 CPU、主板、内存、硬盘、显卡、机箱、显示器、键盘、鼠标等部件组装而成的，采购员不可能自己去组装计算机，而是将计算机的配置要求告诉计算机销售公司，计算机销售公司安排技术人员去组装计算机，然后再交给要买计算机的采购员。
以上所有这些产品都是由多个部件构成的，各个部件可以灵活选择，但其创建步骤都大同小异。这类产品的创建无法用前面介绍的工厂模式描述，只有建造者模式可以很好地描述该类产品的创建。
- 建造者模式： 又叫生成器模式，是一种对象构建模式。它可以将复杂对象的建造过程抽象出来（抽象类别），使这个抽象过程的不同实现方法可以构造出不同表现（属性）的对象。
- 建造者模式，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。
- 建造者模式主要解决在软件系统中，当面临一个复杂对象的创建工作时，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临剧烈的变化，但是将它们组合在一起的算法却相对稳定。
- 主要适用于：一些基本部件不会变，而其组合经常变化的情况。主要是将变与不变进行分离（去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的"套餐"）。
建造者模式的四个角色
1）Product（产品角色）： 包含多个组成部件的复杂对象(产品对象)。
2）Builder（抽象建造者）： 创建一个包含 Product 各个子部件的抽象方法或接口，通常还包含了一个返回复杂产品的方法。
3）ConcreteBuilder（具体建造者）： 实现 Builder 接口，构建和装备各个子部件的具体实现。
4）Director（指挥者）： 构建一个使用 Builder 接口的对象。它主要作用是用于创建一个复杂的对象。在指挥者中不涉及具体产品的信息。主要分两个作用，一是隔离客户与对象的生产过程，二是负责控制对象的生产过程。
建造者模式的注意事项和细节
1）客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
2）每一个具体建造者都相对独立，因此可以方便的替换或者新增具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。
3）可以更加精准的控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
4）增加新的具体建筑者无需修改原有类库代码，指挥者类针对抽象建造者类编程，系统扩展方便。符合 OCP 原则。
5）建造者模式创建的产品具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合建造者模式，因此其使用范围受到一定的限制。
6）如果产品的内部变化复杂，可能会导致需要定义很多具体建造者内来实现这种变化，导致系统变得庞大，因此这种情况下，考虑是否选择建造者模式。
7）抽象工厂模式 VS 建造者模式：抽象工厂模式实现对产品家族的创建，一个产品家族就是一系列产品。具有不同分类维度的产品组合，采用抽象工厂模式不需要关系构建过程，只关系产品由什么工厂生成即可。而建造者模式则是要求按照指定的蓝图建造产品，它主要目的是通过组装零配件而产生一个新产品。
建造者模式原理类图
建造者模式案例
【1】创建 Product 产品角色：
public class Product {
private String CPU;
//主板 mainboard
private String mainboard;
//内存 memory
private String memory;
//.....略
//生成get set 方法 略
}
【2】抽象建造者对象：
public abstract class Builder {
//组合 产品对象
protected Product product = new Product();
//抽象方法
public abstract void buildCpu();
public abstract void buildMainboard();
public abstract void buildMemory();
//返回一个产品对象
public Product getResult() {
return product;
}
}
【3】具体建造者对象：一般会有多个这种对象，都实现 Builder 抽象类。
public class ConcreteBuilder_huawei extends Builder{
@Override
public void buildCpu() {
product.setCPU("华为CPU");
}
@Override
public void buildMainboard() {
product.setMainboard("华为主板");
}
@Override
public void buildMemory() {
product.setMemory("华为内存");
}
}
【4】指挥者类，主要构建组装的流程：返回的是产品对象
public class Director {
//需要将抽象类聚合进来
Builder builder = null;
//创建一个构造器 调用时传入具体的实现类
public Director(Builder builder) {
this.builder = builder;
}
//添加set 方法 用户可以通过此方法修改已有的 建造者对象
public void setBuilder(Builder builder) {
this.builder = builder;
}
//笔记本的组成流程 返回的是产品类
public Product pack_pc() {
builder.buildMainboard();
builder.buildCpu();
builder.buildMemory();
return builder.getResult();
}
}
【5】客户端通过指挥者类调用需要的品牌电脑：
public class Client {
public static void main(String[] args) {
//创建需要的电脑子部件——例如我们要组装的是 华为
ConcreteBuilder_huawei huawei = new ConcreteBuilder_huawei();
//调用指挥者类，将需要的品牌传入，根据控制着中的流程进行组装
Director director = new Director(huawei);
//调用组装方法，返回产品
Product pack_pc = director.pack_pc();
//查看输入的结果
System.out.println(pack_pc.toString());
//结果为：Product [CPU=华为CPU, mainboard=华为主板, memory=华为内存]
}
}
源码分析（StringBuilder）
【1】java.lang.StringBuilder中的建造者模式：
public class OrginBuilder {
public static void main(String[] args) {
StringBuilder builder = new StringBuilder("hello");
builder.append("world");
}
}
【2】进入 append 方法，会发现 StringBuilder 类即就是我们所说的指挥者。建造方法的具体实现是由 AbstractStringBuilder 实现。
@Override
public StringBuilder append(String str) {
super.append(str);
return this;
}
【3】进入 AbstractStringBuilder 类，实现了 Appendable 接口方法，此类已是建造者，只是不能实例化。
public AbstractStringBuilder append(String str) {
if (str == null)
return appendNull();
int len = str.length();
ensureCapacityInternal(count + len);
str.getChars(0, len, value, count);
count += len;
return this;
}
【4】Appendable 接口定义了多个 append 方法（抽象方法），既 Appendle 为抽象建造者，定义了抽象方法。
public interface Appendable {
Appendable append(CharSequence csq) throws IOException;
......
}
原型模式
简介
原型模式（Prototype Pattern）： 是用于创建重复对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。
思想： Java 中 Object 类是所有类的根类，Object 类提供了一个 clone() 方法，该方法可以将一个 Java 对象复制一份，但是需要实现 clone 的 Java 类必须要实现一个接口 Cloneable，该接口表示该类能够复制且具有复制的能力（原型模式）。
- 原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型，创建新的对象。
- 原型模式是一种创建型设计模式，允许一个对象再创建另外一个可定制的对象，无需知道如何创建的细节。
- 工作原理是：通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对像拷贝它们自己来实现创建，及对象的clone()。
原理结构图说明：
1）Prototype：原型类，声明一个克隆自己的接口 clone。
2）ConcretePrototype：具体的原型类，实现一个克隆自己的操作。
3）Client 让一个原型对象克隆自己，从而创建一个新的对象（相当于属性）。
原型模式案例分析
【1】克隆类需要实现 Cloneable 重写 clone 方法。
package com.yintong.principle.singleresponsibility;
//写一个手机的克隆类
public class ConcretePrototype implements Cloneable{
//名称
private String name;
//号码
private Long number;
//构造器
public ConcretePrototype(String name, Long number) {
super();
this.name = name;
this.number = number;
}
@Override
public String toString() {
return "ConcretePrototype [name=" + name + ", number=" + number + "]";
}
// 克隆用到的主要部分
@Override
protected Object clone() throws CloneNotSupportedException {
ConcretePrototype ConcretePrototype = null;
try {
ConcretePrototype = (ConcretePrototype) super.clone();
}catch (Exception e) {
System.out.println(e.getMessage());
}
return ConcretePrototype;
}
}
【2】客户端调用 clone 方法，实现原型模式。
public class Client {
public static void main(String[] args) throws CloneNotSupportedException {
//创建一个对象
ConcretePrototype prototype = new ConcretePrototype("华为", new Long(1568889932));
//通过原型模式完成对象的创建 克隆
ConcretePrototype p2 = (ConcretePrototype)prototype.clone();
}
}
Spring 中的应用
【1】当 scope 配置为 prototype 时，表示原型模式。
<!-- 这里我们的 scope="prototype" 即 原型模式来创建 -->
<bean id="id01" class="com.atguigu.spring.bean.Monster" scope="prototype"/>
【2】查看底层调用：
else if (mbd.isPrototype()) {
// It's a prototype -> create a new instance.
Object prototypeInstance = null;
try {
beforePrototypeCreation(beanName);
prototypeInstance = createBean(beanName, mbd, args);
}
finally {
afterPrototypeCreation(beanName);
}
// *** 创建一个代理类 ***
bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
}
浅拷贝
● 对于数据类型是基本数据类型的成员变量，浅拷贝会直接进行值传递，也就是将该属性值复制一份给新对象。
● 对于数据类型是引用类型的成员变量，比如说成员变量是某个数组、某个类的对象等，那么浅拷贝会进行引用传值，也就是只是将成员变量的引用值（内存地址）复制一份给新对象。因为实际上两个对象的该成员变量都指向同一个实例。在这种情况下，在一个对象中修改该成员变量会影响到另一个对象的该成员变量值。
● 浅拷贝是使用默认的 clone() 方法来实现。
深拷贝
● 复制对象的所有基本数据类型的成员变量值。
● 为所有引用数据类型的成员变量申请存储空间，并复制每个引用数据类型成员变量所引用的对象，直到该对象可达的所有对象。也就是说，对象进行深拷贝要对整个对象进行拷贝。
● 深拷贝的实现方式有两种，第一种是重写 clone 方法来实现深拷贝，第二种是通过序列化实现深拷贝，也是推荐的一种。
深拷贝的两种实现方法
【1】通过调用引用类型的克隆方法，实现深拷贝。缺点就是当引用类型多时，不建议采用。
public class DeepClone implements Cloneable{
//基本数据类型
private String name;
//引用数据类型
private Spare spare;
//重写clone方法，调用引用类型的克隆方法
@Override
protected Object clone() throws CloneNotSupportedException {
DeepClone deepClone = null;
deepClone = (DeepClone)super.clone();
//克隆引用数据类型
deepClone.spare = (Spare) spare.clone();
return deepClone;
}
}
【2】通过序列化的方式，实现深拷贝：也是建议使用的方法。
public class DeepClone implements Serializable{
/**
* 序列化 ID
*/
private static final long serialVersionUID = 1L;
//数据类型 略。。。。
//重写clone方法，调用引用类型的克隆方法
protected Object deepClone(){
ByteArrayOutputStream BOStream = null;
ObjectOutputStream OOSream = null;
ByteArrayInputStream BIStream = null;
ObjectInputStream OIStream =null;
try {
//序列化
BOStream = new ByteArrayOutputStream();
OOSream = new ObjectOutputStream(BOStream);
//将当前对象写入流中
OOSream.writeObject(this);
//反序列化
BIStream = new ByteArrayInputStream(BOStream.toByteArray());
OIStream = new ObjectInputStream(BIStream);
DeepClone deepClone = (DeepClone) OIStream.readObject();
return deepClone;
} catch (Exception e) {
e.printStackTrace();
return null;
}finally {
try {
BOStream.close();
OOSream.close();
BIStream.close();
OIStream.close();
} catch (Exception e2) {
e2.printStackTrace();
}
}
}
}
原型模式的注意事项和细节
1）创建新的对象比较复杂时，可以利用原型模式简化对象的创建过程，同时也能够提高效率。
2）不用重新初始化对象，而是动态地获得对象运行时的状态。
3）如果原始对象发生变化（增加或者减少属性），其他克隆对象也会发生变化，无需修改代码。
4）在实现深克隆的时候可能需要比较复杂的代码。
5）缺点：需要为每一个配置类配置一个克隆方法，这对全新的类来说不是很难,但对已有的类进行改造时，需要修改其源代码，违背了 ocp 原则。
