Builder 模式演义

2023年1月8日 291次阅读 来源: 算法小白

引言

　　不用怀疑，你一定遇到和使用过它，它在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
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞