《重学Java设计模式》笔记—

1. 建造者模式可以解决什么问题

我家里有各种形状的瓷器，盘子或者碗。虽然形状不同，但是所用的材料基本上是一样的，比如土、水、釉、彩这些基本的东西。

但是做不同款式的瓷器，方法是不同的。假如说我现在已经写好了一段代码来生成白瓷碗和白瓷盘，正常运行起来了，这倒也没什么，可是，如果我现在要增加一个工作，制作彩绘马克杯，这样我就得修改已有的代码了。

最简单的修改方式就是加if-else。就像是这样：

if (type = "白瓷碗") {

   makeWhiteBowl(...);

} else if (type = "白瓷盘") {

   makeWhitePlate(...);

} else if (type = "彩绘马克杯") {

   makeColorCup(...);

}

...

Well，看起来还不很严重，那么如果你的业务越来越复杂呢？每次新添加一种type，首先就要去改代码，也许还不止这一处，这是不可忍受的，是很烂的设计。

建造者模式，就是为了解决这种问题出现的一种设计模式。

在GoF的《设计模式》一书中，明确的提及了建造者模式的意图：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

这一论断说明了这么几点：

构建过程和对象相分离，也就是说不要直接去new这个对象；
构建过程抽象出来到一个高层次上。

回到我上面的例子，就是制造瓷器的人和瓷器相分离。客户交给匠人材料和订单，匠人自行制造交付就可以了。

2. 建造者模式的理论

建造者模式中会存在下面几种角色：

建造者（Builder）：接口，用于创建产品的各个部分的抽象；
ConcreteBuilder：实现Builder接口，是具体的建造者；
Director：这个名字看着像“导演”，其实是用于构造Builder对象的；
Product：各类产品，最终被Builder生产出来的东西。

下图是GoF给出的类图：

知道了建造者模式的基本类图结构以后，还需要知道这个模式是如何使用的，如下时序图：

3. 具体编码实现

在《重学Java设计模式》中的建造者模式章节提到了一个装修的例子，但是从这个例子上来看，和GoF的描述还是有一些区别的。

还是以装修为例，书中提到了集中装修风格，其实就对应了几种ConcreteBuilder，例如田园奢华欧式、轻奢田园和现代简约。而这些建造者们都有相同的几种方法：

吊顶
涂墙
铺地板或者地砖

另外还有物料，比如各种品牌的装修材料等等。下面是我根据GoF的理论，对《重学Java设计模式》的建造者代码的改造。

首先是物料，可以抽象出一个Matter接口，所有的地板，涂料都是Matter。

/**

 * 物料的五种属性

 */

public interface Matter {

    //类型，比如地板

    String scene();

    //品牌

    String brand();

    //型号

    String model();

    //价格

    BigDecimal price();

    String desc();

}

物料并非建造者模式中的核心元素，接下来就可以抽象建造者了。

package com.example.pattern.builder.iface;

public interface IBuilder {

    //装吊顶

    IBuilder appendCeiling(Matter ceiling);

    //涂墙

    IBuilder appendCoat(Matter coat);

    //铺地板

    IBuilder appendFloor(Matter floor);

    //铺地砖

    IBuilder appendTitle(Matter title);

    //得到装修报价单

    String getResult();

}

建造者要做的工作就是来料加工，也就是一个装修工人的手艺了。

下面是对Director的定义，可以认为Director是监工吧，业主只和监工或者工头直接联系，不会给工人直接下达任务：

package com.example.pattern.builder.builder;

import com.example.pattern.builder.iface.IBuilder;

import com.example.pattern.builder.iface.Matter;

import lombok.Data;

@Data

public class Director {

    private IBuilder builder;

    private Matter ceiling;

    private Matter coat;

    private Matter floor;

    private Matter title;

    public Director(IBuilder builder) {

        this.builder = builder;

    }

    public String construct() {

        return builder.appendCeiling(ceiling).appendCoat(coat)

                .appendFloor(floor).appendTitle(title).getResult();

    }

}

其实Director也不知道自己的物料是什么。从时序图上来看，不管是具体的建造者还是Director都是使用者（就像业主）提供的，因此使用者的代码如下：

public class BuilderApp {

    public static void main(String[] args) {

        IBuilder europeBuilder = new EuropeBuilder(new BigDecimal(160));

        Director director = new Director(europeBuilder);

        director.setCeiling(new LevelTwoCeiling());

        director.setFloor(new MarcoPoloTitle());

        director.setCoat(new NipponCoat());

        String result = director.construct();

        System.out.println(result);

    }

}

这个结果就是计算一下装修的账单，很简单的一个示例，最终的打印是总报价。

4. 进一步的思考

在结城浩的《图解设计模式》一书中提到了“谁知道什么”的概念。在上面的代码中，这个概念体现了两次：

BuilderApp类并没有直接调用Builder，BuilderApp并不知道Builder能做什么；
Director也不知道自己到底调用的是哪个Builder，它使用的是一个接口。

OOP一定是面向接口最好的，因为可以随时替换掉具体的实现，不同的类之间耦合度不高。

在新增一个产品的时候，只需要添加一个具体的Builder就可以了，不需要修改现有代码。

学习一种设计模式总是写这种简单的例子也感觉没什么意思。我在之前的工作中因为一些原因不能用现成的第三方包，就只能写了一个Map的生成器来做事情，我觉得这个倒是挺有建造者模式的味道的。

首先我不需要定义Map了，因为Java.util已经提供了足够多的，而且是接口和实现分离的。

下面需要定义一个Builder：

package com.example.pattern.builder.maphelper;

import java.util.Map;

public class MapBuilder<K, V> {

    private Map<K, V> map;

    public MapBuilder(Map<K, V> map) {

        this.map = map;

    }

    public MapBuilder<K, V> put(K k, V v) {

        map.put(k, v);

        return this;

    }

    public Map<K, V> build() {

        return map;

    }

}

这个Builder更好的地方就是自己都不知道自己制造什么产品。接下来时Director的角色：

package com.example.pattern.builder.maphelper;

import java.util.Map;

public class MapHelper {

    public static <K, V> MapBuilder<K, V> builder(Map<K, V> map) {

        return new MapBuilder<>(map);

    }

}

这简直太让人舒适了，因为调用者的代码是链式的：

Map<String, String> map

                = MapHelper.builder(new HashMap<String, String>()).put("foo", "bar")

                .build();

这个建造者和GoF的理论有一点差异，就是MapHelper并没有持有任何对象，没有构造方法。其实如果一定要改造也是可以的。

Map本身是一个比较复杂的构建，因为要不停的put，代码也显得不够漂亮，链式put则显得优雅一些。而且这个Builder本身也实现了构建和表示分离的原则。