【设计模式】Builder

前言

Builder设计模式，允许一步一步构建一个复杂的对象。将构建步骤抽象出来，让每个具体的Builder去实现构建步骤的内容。这样子就可以用同样的构建步骤，构建出不一样的对象。在Director类的协助下，可以将固定的构建步骤封装起来，给Director一个Builder，让Director来调用Builder的具体构建步骤。

变的是什么呢？构建步骤的具体内容
不变的是什么呢？

分析

见到Builder设计模式，更多时候Director就是你自己！你需要自己去调用Builder的构建步骤去构建想要的对象。这么做的好处是隐藏了细节，很多细节调用者并不关心，这些细节都是一样的，那么将他们封装到具体的函数中，调用者给出最少需要的信息即可。

适用场景

当一个类的构造函数需要的参数过多的时候，可以考虑使用Builder设计模式。

源码分析

AlertDialog.Builder

为什么说Builder的好处之一是隐藏细节呢？请看setTitle这个函数。

当使用Builder调用这个setTitle函数的时候，调用方只需要给出titleId，Builder调用Context的方法获取String，然后将之存到AlertParams中。这只是其中的一个例子。其他的比如，输入信息，Builder去new一个对象，然后设置AlertParams。这些查字符串，创建对象等操作，只需要调用者给出信息即可在背后完成。

最后调用create()或者show()来创建一个AlertDialog，根据AlertParams的参数去设置AlertDialog，然后调用AlertParams.apply设置它的AlertController。

自己实现Builder的时候，可以参考它的做法，返回this，可以连在一起setXXX。

AlertDialog.java下面的Builder类

private final AlertController.AlertParams P;

public Builder setTitle(@StringRes int titleId) {
    P.mTitle = P.mContext.getText(titleId);
    return this;
}

public AlertDialog create() {
    // Context has already been wrapped with the appropriate theme.
    final AlertDialog dialog = new AlertDialog(P.mContext, 0, false);
    P.apply(dialog.mAlert);
    ...
    return dialog;
}

AlertController.java下面的AlertParams类

public void apply(AlertController dialog) {
    ...
    if (mMessage != null) {
        dialog.setMessage(mMessage);
    }
    if (mPositiveButtonText != null) {
        dialog.setButton(DialogInterface.BUTTON_POSITIVE, mPositiveButtonText,
                mPositiveButtonListener, null);
    }
    ...
}

Director

这里想到了一个强行应用Director的例子。在一个Activity中，有几个创建AlertDialog的过程，这些过程除了SetMessage不一样之外，其他部分都一样。如果确定了这些AlertDialog的风格一致，除了Message不一样，可以创建一个Director类，传入一个Builder，传入要显示的String，让Director来指挥Builder干活。

确保是在真的大量重复创建风格相同的AlertDialog的前提下使用。至于好处嘛，比如当要更改ALertDialog的风格，每一个都要去做修改。如果使用了Director，只要告诉Director你该怎么改，岂不是美滋滋。