Android 内功心法(1.10)——android常用设计模式之建造者（Builder）模式

目的：

如果你的对象相对复杂，那么就应该考虑对象的构建和它的表现相分离。目的是为了同样的构建过程可以创建不同的表示。

在android中我们创建dialog的时候就是建造者模式的最好体现。

AlertDialog alertDialog = new AlertDialog.Builder(getContext()).setView(new EditText(getContext())).create();

我们先来看看android源码中实现builder模式是如何实现的，这里我借鉴朋友的博客java设计模式——-Builder模式里面的一个构建复杂数据的例子来说明：

public class NutritionFacts {
private int servingSize = 0; // 食用份量
private int servings; // 份数
private int calories; // 卡路里
private int sodium; // 钠
private int fat; // 脂肪
private int carbohydrate; // 碳水化合物

public static class Builder {

private int servingSize = 0; // 食用份量
private int servings; // 份数
private int calories; // 卡路里
private int sodium; // 钠
private int fat; // 脂肪
private int carbohydrate; // 碳水化合物

public Builder(int servingSize, int servings) {
this.servingSize = servingSize;
this.servings = servings;
}

public Builder calories(int calories) {
this.calories = calories;
return this;
}

public Builder sodium(int sodium) {
this.servingSize = sodium;
return this;

}

public Builder fat(int fat) {
this.fat = fat;
return this;
}

public Builder carbohydrate(int carbohydrate) {
this.carbohydrate = carbohydrate;
return this;
}

public NutritionFacts show() {
return new NutritionFacts(this);
}

}

private NutritionFacts(Builder builder) {
servings = builder.servings;
servingSize = builder.servingSize;
calories = builder.calories;
carbohydrate = builder.carbohydrate;
fat = builder.fat;
sodium = builder.sodium;
}

}

这就是类似android源码中dialog的builder模式，我们用这种方式去创建一个复杂的数据结构是非常简单和方便的。

调用方法：

NutritionFacts nutritionFacts = new NutritionFacts
.Builder(20, 8)
.calories(20)
.carbohydrate(50)
.fat(60)
.show();

这个数据结构是不是很想android中new一个AlertDialog的写法？

我们去翻看AlertDialog源码你就会发现，其实是一模一样的写法。

这样得到的nutritionFacts实例你可以实现部分数据，也可以实现全部数据。

but！

如果你觉得这就是builder模式了，那你就太小看它的魅力了。

以上代码只是一个简单的示范，我要说的是builder模式的实现原理和工作方式。

在我看来以上这种builder模式是最简单的但并非最好的。

以上代码适合一个房子的建造，比如AlertDialog。如果你在建立一个AlertDialogA或者AlertDialogB。建立一个类似的房子的时候是不是需要重新写一个AlertDialogA或者AlertDialogB的代码呢？

所以，以上代码是有问题的。

第一，强耦合；

第二，必须声明静态；

第三，不符合开闭原则。

首相我们要搞清楚一个builder模式需要什么东西。

1，一个需要被建造出来的对象。比如房子。（dialog）

2，一个建造房子的工人。（builder）

3，指挥工程师如何建房子的工程师。比如指挥者。（director）

4,一个对象的建造，哪些是必须的，哪些是非必须的。就像一栋房子的房梁，墙体，房顶，这是必须的。但是贴瓷砖、建围墙、装修豪华这些是非必须的。

只要一个builder模式完成了这四个部分，那么你再造一栋房子，不用重复了，只需要在原来做过的这栋房子上稍加改造就行了。

具体看代码实现吧。

/**
* 抽象建造者类，包含一个建造者必须建造的具体产品，还有一些制造产品的零件，零件不是必须的。
*/
public abstract class Builder {

public abstract void buildPartA();//零件a

public abstract void buildPartB();//零件b

public abstract void buildPartC();//零件c

public abstract Product getPart();//得到由建造者建造的具体产品

}

/**
* 建造者具体实现类
*/
public class ConcreteBuilderA extends Builder {

private Product product = new Product();

@Override
public void buildPartA() {
product.addPart("这个产品必须的零件a");
Log.i("test", "制造零件a");
}

@Override
public void buildPartB() {
product.addPart("这个产品必须的零件b");
Log.i("test", "制造零件b");
}

@Override
public void buildPartC() {
product.addPart("这个产品必须的零件b");
Log.i("test", "制造零件c");
}

//返回一个制造出来的具体产品
@Override
public Product getPart() {
return product;
}

}

/**
* 指挥者类
* 指挥者决定让建造者必须建造哪些零件
* 相当于指挥者对建造者说，房梁，墙体，房顶，必须建造
*/
public class Director {
public void cunstruct(Builder builder) {
builder.buildPartA();//创建零件a
builder.buildPartB();//创建零件B
//builder.buildPartC();//创建零件C，这栋房子不需要零件c
}
}

/**
* 产品类，由多个零件组成；
* 一个产品可以添加很多的属性，这些属性不是必须的
* 就相当于一个基本完成的房子包含好多操作：刷墙，贴瓷砖，装修、建立围墙
* 这些操作不是必须的
*/
public class Product {

List<String> parts = new ArrayList<>();

public void addPart(String part) {
parts.add(part);
}

public void getPartTile(String title) {//得到由建造者建造的名称
Log.i("test", "设置产品标题");
}

public void getPartMessage(String message) {//得到由建造者建造的简介
Log.i("test", "设置产品介绍");
}

public Button getPartButton(Button button) {//得到由建造者建造的操作按钮
return button;
}

//将这个产品类展示出来，房子完工
public void show() {
for (String part : parts) {
Log.i("test", part);
}
}
}

到这里。已经完工了。

1，抽象建造者控制必须建造的方法。（老板。这里的一切我说了算）

2，具体建造者（工人）执行建造。

3，指挥者（工程师）决定建造者建造哪些方法。

4，产品类。所有的老板，工人，工程师都是围绕着如何建立这个产品而生的。

我们来看看使用方法：

Director director = new Director();//实例化一个指挥者
Builder builder = new ConcreteBuilderA();//实例化一个建造者
director.cunstruct(builder);//指挥者告诉建造者你必须要建造哪几个类，必须创建的类是抽象建造者中包含的抽象方法，而指挥者告诉建造者，这部分的抽象方法必须实现，因为这是必不可少的。
Product product = builder.getPart();//具体要建造的产品，它其中有很多方法，这些方法可以全部实现，也可以部分实现
product.addPart("非必需零件a");
product.addPart("非必需零件b");
product.getPartMessage("这是一个dialog");
product.getPartTile("dialog的标题");
product.getPartButton(new Button(context));
product.show();

这种builder比较复杂，但是它的确符合设计模式的六大原则。

如果你用这中方式创建一个AlertDialog。那么你同样可以用这中方式创建一个AlertDialogA或者更多类似的产品。

我们只需要在抽象建造者类中控制所有必须方法。

然后再创建一个工程师，称之为建造AlertDialogA的工程师，它告诉BuilderA(AlertDialogA的工人)建造AlertDialogA的必须方法。

再创建一个工人，称之为AlertDialogA的工人。完成工程师交代的任务。

最后，拿出ProductA产品的蓝图。

test，开工！

代码没有重复，没有修改原来建造的AlertDialog，相反拓展了AlertDialogA的创建方式。

这才是一个合格的或者说最好的设计模式实现方法。

这里要说明的一点是，并非android源码中用到的设计模式就是最终形态。它也只是在适合的场景用到了适合的设计模式。

它代表的是最合适的场景+最合适的代码方式；并非最好的设计模式的具体体现。

认清真相很重要，做对很重要。