Builder 模式演义

引言

  不用怀疑,你一定遇到和使用过它,它在Android源码和各种开源组件中是如此常见。这是一种你可以不知道怎么运用,但是知道了会欲罢不能的设计模式。

定义

  Builder模式(建造者模式,有人称作生成器模式),将一个复杂对象的构建与他的表示分离,使得同样的构建过程可以创建不同的表示。
  很抽象?请看如下UML类图,进行直观的描述。

UML类图

  这是在许多书籍、网络资料中非常容易找到的标准Builder设计模式类图。

《Builder 模式演义》

GoF标准Builder模式类图.png

角色

  在上图中可以清楚地看到Builder模式里的四种角色。

  1. Builder:抽象的建造者。
  2. ConcreteBuilder:具体的建造者,继承自Builder,通常不止一个
  3. Product:被构造的复杂对象
  4. Director:指挥者,指挥建造者去建造一个产品

  上图中的ConcreteBuilder和Product是一一对应关系,实际上,ConcreteBuilder和Product并不只有一对,因此Builder模式的实际UML类图呈现如下形式。

《Builder 模式演义》

拓展Builder模式类图.png

  细心的你早已洞察一切,拿掉Director角色后,上下两部分是一个对称结构。而上文也提到,Builder常常以内部类的形式出现。因此,抽象的Builder定义在抽象的Product内部,具体的ConcreteBuilderA定义在具体的ProductA内部,具体的ConcreteBuilderB定义在具体的ProductB内部……

Builder模式的简单实现

  以上描述实在太过抽象,具体的示例代码早已呼之欲出。
  Computer类对应于Product角色,它的内部定义了一个静态的Builder类。配置和初始化都交给Builder去做了,因此Computer本身并不提供对任何属性的setter,也不提供以任何属性为参数的构造函数。

public class Computer {
    protected String mBoard;
    protected String mDisplay;
    protected String mOS;

    protected Computer(Builder builder) {
        this.mBoard = builder.board;
        this.mDisplay = builder.display;
        this.mOS = builder.os;
    }

    public static abstract class Builder {
        protected String board;
        protected String display;
        protected String os;

        public abstract Computer.Builder buildBoard(String board);
        public abstract Computer.Builder buildDisplay(String display);
        public abstract Computer.Builder buildOS();
        public abstract Computer build();
    }

    @Override
    public String toString() {
        return "Computer [mBoard=" + mBoard + ", mDisplay=" + mDisplay + ", mOS=" + mOS + "]";
    }
    //Computer其他重要操作
}

  MacBook是Computer的一个子类,对应于ProductA角色。它内部也定义了一个Builder类,对应于ConcreteBuilderA角色。因为是内部类,所以也叫Builder,不存在重名的问题。注意它的最后一个方法build(),返回一个Macbook对象,这是非常关键的一步。

public class Macbook extends Computer {
    public Macbook(Builder builder) {
        super(builder);
    }

    public static class Builder extends Computer.Builder {

        @Override
        public Computer.Builder buildBoard(String board) {
            this.board = board;
            return this;
        }

        @Override
        public Computer.Builder buildDisplay(String display) {
            this.display = display;
            return this;
        }

        @Override
        public Computer.Builder buildOS() {
            this.os = "Mac OS X 10.10";
            return this;
        }

        @Override
        public Computer build() {
            return new Macbook(this);
        }
    }
}

  Computer的其他子类,如SurfacePro.java代码和Macbook类似,限于篇幅,不在此贴出。再看Director和客户端测试代码。

public class Director {
    private Computer.Builder mBuilder;

    public Director(Computer.Builder builder) {
        this.mBuilder = builder;     }

    public void buildPC(String board, String display) {
        mBuilder.buildBoard(board);         mBuilder.buildDisplay(display);         mBuilder.buildOS();     }
}
Computer.Builder builder = new Macbook.Builder(); Director director = new Director(builder); director.buildPC("Inter Board", "Apple Display");

Computer.Builder builder2 = new SurfacePro.Builder(); director = new Director(builder2); director.buildPC("AMD Board", "LG Display");

System.out.println(builder.build().toString()); System.out.println(builder2.build().toString());

  毫无悬念地,我们得到了想要的输出。

Computer [mBoard=Inter Board, mDisplay=Apple Display, mOS=Mac OS X 10.10]
Computer [mBoard=AMD Board, mDisplay=LG Display, mOS=Windows 10]

Builder模式的变形

  细心的你又发现了,Computer.Builder中的三个抽象方法都都是有返回值的,在Macbook.Builder中可以看到这三个方法的具体实现中,都是先操作完Builder本身(对builder的属性进行赋值)然后再返回Builder本身。但是我们在调用这三个方法的时候(Director类的buildPC方法中)并没有使用到这一返回值。现在尝试使用它!

    public void buildPC(String board, String display) {
// mBuilder.buildBoard(board);
// mBuilder.buildDisplay(display);
// mBuilder.buildOS();
        mBuilder.buildBoard(board).buildDisplay(display).buildOS();
    }

  保存、编译、运行,输出结果一样,完全没毛病啊!将一句话封装成一个方法,还多了个类,Director是不是多余啊?试试不用Director,进行同义替换。

Computer macbook = new Macbook.Builder()                 .buildBoard("Inter Board")                 .buildDisplay("Apple Display")                 .buildOS()                 .build(); System.out.println(macbook.toString());

  这就是我们常见的链式调用,非常方便易用!

小结

  回到文章开头的Builder模式定义,复杂对象Macbook以三个属性board、display、和OS三个属性以及其他重要方法来表示,但是它的构建既不直接使用构造函数,也不对外提供setter,也不提供其他方法直接操作三个属性。而是金蝉脱壳,将构建和初始化过程转交给了内部的Builer去实现,此所谓“构建和表示分离”。
  因为Product角色存在着明显的继承派生关系,Builder角色也与之一一对应,从上述代码示例可以看出,mBuilder.buildBoard(board).buildDisplay(display).buildOS()是统一的三部曲过程,最后的输出中Macbook和SurfacePro却是不同的配置。此所谓“同样的构建过程创建不同的表示”。

后记

  限于篇幅,本文只讨论了Builder模式的两种变换:链式调用省略指挥者角色。其实设计模式的应用非常灵活,Builder模式不但可以省略指挥者,连抽象Builder角色都可以省略。再者,由于Builder模式本身的特性,一旦Builder调用build()方法生成相应的Product对象,Product对象的任何属性值便无法再改变。哪怕Product中的99个属性相同,只有1个不同,也必须重新构建,无法复用。
  敬请期待,本文的续篇
  OkHttp源码中的Builder模式
为您讲述Builder模式变换之“省略抽象Builder角色”“Product的回炉再造”

    原文作者:算法小白
    原文地址: https://juejin.im/entry/58ca38a45c497d0057af6d32
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞