SilverLining's Blog

创建型模式-原型模式与建造者模式

原型模式

原型模式 (Prototype Pattern) 是指原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象,属于创建型模式。

原型模式的核心在于拷贝原型对象。以系统中已存在的一个对象为原型,直接基于内存二进制流进行拷贝,无需再经历耗时的对象初始化过程(不调用构造函数),性能有较大提升。

原型模式主要包含三个角色:

对不通过 new 关键字,而是通过对象拷贝来实现创建对象的模式就称作原型模式。

原型模式主要适用于以下场景:

  1. 类初始化消耗资源较多。
  2. 每次新创建一个对象需要非常繁琐的过程(数据准备、访问权限等)
  3. 构造函数比较复杂。
  4. 循环体中生产大量对象时。

案例

举个例子,我们有一个 Student 对象:

public class Student {
    private int grade;
    private int classroom;
    private String name;
    private int age;
    private String major;
}

当我们要给计算机专业三年级二班添加以为新同学时,可能会有这样的代码:

Student stu = queryObject("SELECT * FROM tb_student WHERE grade = 3 AND classroom = 2 AND major = 'CS' LIMIT 1");
Student newStu = new Student();
newStu.setGrade(stu.getGrade());
newStu.setClassroom(stu.getClassroom());
newStu.setName("Tom");
newStu.setAge(20);
newStu.setMajor(stu.getMajor());

如果 Student 这个类有非常多的属性,这样的方式就太繁琐了。我们可能会想到利用反射实现一个稍微偷懒的方式:

public class BeanUtils {
    public static Object copy(Object protorype) {
        Class clazz = protorype.getClass();
        Object returnValue = null;
        try {
            returnValue = clazz.getConstructor().newInstance();
            for (Field field : clazz.getDeclaredFields()) {
                field.setAccessible(true);
                field.set(returnValue, field.get(protorype));
            }
        } catch(Exception e) {
            e.printStackTrace();
        }
        return returnValue;
    }
}

虽然看起来优雅了些,但基于反射的实现还是存在着必须属性命名严格一致,性能低下的问题,并且实现原理上也和手动 get,set 没有本质区别。

浅克隆

这时,我们的目光转向了 JDK 自带的一个接口:Cloneable
首先来看我们的原型对象:

public class StudentPrototype implements Cloneable {
    private int age;
    private String name;
    private List<String> courses;

    @Override
    public StudentPrototype clone() {
        try {
            return (StudentPrototype)super.clone();
        } catch (CloneNotSupportedException e) {
            e.printStackTrace();
            return null;
        }
    }
}

然后测试一下通过浅克隆来新建一个 Student:

public class ShallowCloneTest {
    public static void main(String[] args) {
        StudentPrototype studentPrototype = new StudentPrototype();
        // prepare prototype
        studentPrototype.setAge(18);
        studentPrototype.setName("Tom");
        List<String> courses = new ArrayList<String>();
        courses.add("Java course");
        courses.add("Python course");
        studentPrototype.setCourses(courses);

        // shallow clone
        StudentPrototype student1 = studentPrototype.clone();
        System.out.println("Prototype: " + studentPrototype.toString());
        System.out.println("Cloned: " + student1.toString());
    }
}

看一下输出结果,看起来好像没什么问题:

Prototype: StudentPrototype{age=18, name='Tom', courses=[Java course, Python course]}
Cloned: StudentPrototype{age=18, name='Tom', courses=[Java course, Python course]}

但是我们稍作深入,浅克隆的问题就暴露了:

// alter prototype attributes
student1.getCourses().add("AI course");
System.out.println("Prototype: " + studentPrototype.toString());
System.out.println("Cloned: " + student1.toString());

输出结果:

Prototype: StudentPrototype{age=18, name='Tom', courses=[Java course, Python course, AI course]}
Cloned: StudentPrototype{age=18, name='Tom', courses=[Java course, Python course, AI course]}

我们明明修改的是克隆出的新对象的 Courses 属性,结果连原型对象也一并被修改了。这显然不符合我们的预期。因为我们希望克隆出来的对象应该和原型对象是两个独立的对象,不应该再有联系了。

从测试结果来看,浅克隆正如其名,对于基本数据类型,他完美的完成了拷贝的任务,但是对于列表类型,则只是拷贝了一份引用,指向的却仍然是同一个内存地址。因此我们修改任意一个对象中的属性值,prototype 和 cloneType 的 courses 值都会改变。

有同学可能会说,这个问题好解决啊,既然浅克隆默认只复制值对象,那我们自己把引用对象拷贝一份不就可以了么:

public class StudentPrototype implements Cloneable {
    private int age;
    private String name;
    private List<String> courses;

    @Override
    public StudentPrototype clone() {
        try {
            StudentPrototype newStudent = (StudentPrototype)super.clone();
            List<String> newCourses = newStudent.getCourses().clone();
            newStudent.setCourses(newCourses);
            return newStudent;
        } catch (CloneNotSupportedException e) {
            e.printStackTrace();
            return null;
        }
    }
}

这样做确实能解决我们现有的问题,可是如果还有 List<List<CustomObject>> 这样的类型呢?还要去嵌套实现 List 中的 List,甚至 CustomObject 中所有属性的克隆吗?显然这并不是一个通用的解决方法。

深克隆

为了解决浅克隆存在的问题,我们继续来看深克隆。

深克隆的三种方式:

  1. 手动赋值(用反射手动赋值);
  2. 序列化与反序列化,要求拷贝的对象实现了 Serializable 。然而有些限制,比如 Map 类不支持,使用 HashMap 即可;
  3. 利用 JSON 对象克隆,本质上是反射。

来看一下分别基于序列化和基于 JSON 的深克隆方式:

public interface ICloneablePrototype<T> {
    T deepCloneJSON();
    T deepCloneSerializable();
}

public class StudentPrototype implements ICloneablePrototype<StudentPrototype>, Serializable {
    public StudentPrototype deepCloneSerializable() {
        try {
            ByteArrayOutputStream bos = new ByteArrayOutputStream();
            ObjectOutputStream outputStream = new ObjectOutputStream(bos);
            outputStream.writeObject(this);

            ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
            ObjectInputStream ois = new ObjectInputStream(bis);
            return (StudentPrototype) ois.readObject();

        } catch (Exception e){
            e.printStackTrace();
            return null;
        }
    }

    public StudentPrototype deepCloneJSON() {
        Gson gson = new Gson();
        String json = gson.toJson(this);
        return gson.fromJson(json, this.getClass());
    }
}

克隆破坏单例模式

如果我们克隆的目标的对象是单例对象,那就意味着,克隆方法会可以绕过构造方法创建一个新对象,从而破坏了单例。实际上防止克隆破坏单例的解决思路非常简单:

  1. 单例不实现 Cloneable 接口
  2. 重写 clone()方法直接返回单例对象即可
@Override
protected Object clone() throws CloneNotSupportedException {
    return INSTANCE;
}

JDK 中的原型模式

先看 JDK 中的 Cloneable 接口,只有一个标记定义:

public interface Cloneable {
}

继续找找看哪些接口实现了 Cloneable 接口,例如 ArrayList 类:

public class ArrayList<E> extends AbstractList<E> implements List<E>, RandomAccess, Cloneable, Serializable {
    public Object clone() {
        try {
            ArrayList<?> v = (ArrayList)super.clone();
            v.elementData = Arrays.copyOf(this.elementData, this.size);
            v.modCount = 0;
            return v;
        } catch (CloneNotSupportedException var2) {
            throw new InternalError(var2);
        }
    }
}

可以看到,ArrayList 类的 clone 方法中只是将 List 中的元素遍历拷贝了一遍。那么我们再思考一下,这样的形式真的实现了数组的深克隆吗?用代码简单验证一下就知道了:

class Element {
    public int a;
}

public class DeepCloneTest {
    public static void main(String[] args) {
        ArrayList<Element> list1 = new ArrayList<Element>();
        Element ele = new Element();
        list1.add(ele);
        ArrayList<Element> list2 = (ArrayList<Element>)list1.clone();
        System.out.println(list1 == list2);                 // false
        System.out.println(list1.get(0) == list2.get(0));   // true
    }
}

真相只有一个:ArrayList 的 clone 方法也是浅克隆,内部的引用对象还是同一份。

一般的,实现了 Cloneable 接口的对象的 clone 方法都是浅克隆。

原型模式的优缺点

优点:

缺点:

建造者模式

建造者模式 (Builder Pattern) 是将一个复杂对象的构建过程与它的表示分离,使得同样的构建过程可以创建不同的表示,属于创建型模式。

使用建造者模式,只需指定需要建造的类型,就可以获得对象而不需要了解对象的建造过程及细节。

建造者模式适用于创建对象需要很多步骤,但是步骤的顺序不一定固定。如果一个对象有非常复杂的内部结构(很多属性),可以将复杂对象的创建和使用(属性设置)的操作分离。

建造者模式的设计中,主要有四个角色:

  1. 产品 (Product):要创建的产品类对象。
  2. 建造者抽象 (Builder):建造者的抽象类,规范产品对象的各个组成部分的建造,一般由子类实现具体的建造过程。
  3. 建造者 (ConcreteBuilder):具体的 Builder 类,根据不同的业务逻辑,具体化对象的各个组成部分的创建。
  4. 调用者 (Director):调用具体的建造者,来创建对象的各个部分,在指导者中不涉及具体产品的信息,只负责保证对象各部分完整创建或按某种顺序创建。

应用场景

建造者模式适用于一个具有较多的零件的复杂产品的创建过程。由于需求的变化,组成这个复杂产品的各个零件经常有着很大的变化,但是它们的组合方式却相对稳定。

建造者模式适用于以下几种场景:

  1. 相同的方法,不同的执行顺序会产生不同的结果时。
  2. 多个部件或零件,都可以装配到一个对象中,但是产生的结果又不相同。
  3. 产品类非常复杂,或者产品类中的调用顺序不同产生不同的作用。
  4. 当初始化一个对象特别复杂,参数多,而且很多参数都具有默认值时。

大部分建造者模式的对象还支持链式写法,说到这里相信大部分人都懂了:

StringBuilder sb = new StringBuilder("StringBuilder ")
                        .append("hello").append(" ")
                        .append("world").append("!");
System.out.println(sb.toString());

而这个链式写法的神奇之处,其实就在于其特殊的返回值:

public final class StringBuilder extends AbstractStringBuilder implements Serializable, Comparable<StringBuilder>, CharSequence {

    public StringBuilder append(String str) {
        super.append(str);
        return this;
    }
}

MyBatis 中的建造者模式

MyBatis 中的 CacheBuilder 类,通过构建各种装饰然后最后再构建对象:

public class CacheBuilder {
    private final List<Class<? extends Cache>> decorators;
    public CacheBuilder addDecorator(Class<? extends Cache> decorator) {
        if (decorator != null) {
            this.decorators.add(decorator);
        }
        return this;
    }

    public Cache build() {
        setDefaultImplementations();
        Cache cache = newBaseCacheInstance(implementation, id);
        setCacheProperties(cache);
        // issue #352, do not apply decorators to custom caches
        if (PerpetualCache.class.equals(cache.getClass())) {
            for (Class<? extends Cache> decorator : decorators) {
                cache = newCacheDecoratorInstance(decorator, cache);
                setCacheProperties(cache);
            }
            cache = setStandardDecorators(cache);
        } else if (!LoggingCache.class.isAssignableFrom(cache.getClass())) {
            cache = new LoggingCache(cache);
        }
        return cache;
    }
}

再来看另一个类 SqlSessionFactoryBuilder

public class SqlSessionFactoryBuilder {

    public SqlSessionFactory build(Reader reader) {
        return build(reader, null, null);
    }

    public SqlSessionFactory build(Reader reader, String environment) {
        return build(reader, environment, null);
    }

    public SqlSessionFactory build(Reader reader, Properties properties) {
        return build(reader, null, properties);
    }

    public SqlSessionFactory build(Reader reader, String environment, Properties properties) {
        try {
            XMLConfigBuilder parser = new XMLConfigBuilder(reader, environment, properties);
            return build(parser.parse());
        } catch (Exception e) {
            throw ExceptionFactory.wrapException("Error building SqlSession.", e);
        } finally {
            ErrorContext.instance().reset();
            try {
                reader.close();
            } catch (IOException e) {
                // Intentionally ignore. Prefer previous error.
            }
        }
    }
}

Spring 中的建造者模式

在 Spring 中自然也少不了建造者模式的身影,比如 BeanDefinitionBuilder 类,通过调用 getBeanDefinition()方法构建 BeanDefinition 对象:

public final class BeanDefinitionBuilder {
    public AbstractBeanDefinition getBeanDefinition() {
        this.beanDefinition.validate();
        return this.beanDefinition;
    }
}

其中决定可以构建的类型的方法有 genericBeanDefinitionchildBeanDefinitionrootBeanDefinition 等等,可装配的属性有 setFactoryMethodsetInitMethodNamesetScope 等等,然而不管是什么类型,装配怎样的属性,其最终构建的一定是 AbstractBeanDefinition 这个类的对象。

因此当我们需要创建一个 BeanDefinition 的时候,不需要在创建时就指出需要创建的类型,创建完成后可以按照我们需要进行装配,最后就可以构建出我们想要的对象。

建造者模式小结

建造者模式的优点:

建造者模式的缺点:

建造者模式和工厂模式的区别

  1. 建造者模式更加注重方法的构建组成,工厂模式注重于创建对象。
  2. 创建对象的粒度不同,建造者模式创建复杂的对象,由各种复杂的部件组成,工厂模式创建出来的是标准对象。
  3. 关注重点不一样,工厂模式模式只需要把对象创建出来就可以了,而建造者模式中不仅要创建出这个对象,还要知道这个对象由哪些部件组成。
  4. 建造者模式根据建造过程中的顺序不一样,最终的对象部件组成也不一样。