【源码分析设计模式 10】SpringMVC中的建造者模式

一、基本介绍

建造者模式就是将一个个简单的对象一步一步构建成一个复杂的对象。

我们生活中有很多可以用建造者模式来解释。譬如在生产汽车的流水线作业中，我们需要先将生产汽车所需的一个一个的内部构建建造出来，例如发动机，车门，车轮，方向盘，水箱等。对于我们用户来说，我们并不需要知道这个汽车是怎么建造出来的，各个部件是怎么组装的，销售人员也不需要知道这个汽车是怎么组装建造的，我们只需要知道这是一辆汽车，我们可以销售和使用就行了，对于销售人员只需要知道客户需要什么样的汽车，他告诉建造者模式中的指挥者去生产对应的车就可以了，哈哈哈，这都是工业4.0了；同样，我们看一个简单的例子，在一家快餐店中，服务员也不需要知道厨师是怎么炒菜和做饭的，她只需要告诉厨师客户需要什么样的套餐类型就可以了。像这样，建造者返回给客户一个完整的的产品对象，而客户端无须关心该对象所包含的额属性和组建方式，这就是建造者模式的设计动机。

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

二、建造者模式的结构

1、抽象建造者（Builder）

它声明为创建一个产品对象的各个部件指定的抽象接口，在该接口中一般声明两类方法，一类方法是buildPatX()，他们用于创建复杂对象的各个部件；另一类方法是getResult()，它们用于返回复杂对象。Builder既可以是抽象类，也可以是接口。

2、具体建造者（ConcreteBuilder）

实现抽象建造者接口，构建和装配各个部件，定义并明确它所创建的复杂对象，也可以提供一个方法返回创建好的复杂产品对象。

3、指挥者（Director）

它负责安排复杂对象的建造次序，指挥者与抽象建造者之间存在关联关系，可以在其construct()构造方法中调用建造者对象的部件构造与装配方法，完成复杂对象的建造。客户端一般只需要与指挥者进行交互，在客户端确定具体建造者的类型，并实例化具体建造者对象（也可以通过配置文件和反射机制），然后通过指挥者类的构造函数或者setter方法将该对象传入指挥者类中。它主要是用于创建一个复杂对象，它主要有两个作用①隔离了客户与对象的生成过程②负责控制产品对象的生产过程。

4、产品（Product）

产品角色，一个具体的产品对象。

三、建造者模式的优缺点

1、优点

（1）在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。

（2）每一个具体建造者都相对独立，而与其它的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。由于指挥者类针对抽象建造者编程，增加新的具体建造者无须修改原有类库的代码，系统扩展方便，符合“开闭原则”。

（3）可以更加精细的控制产品的创建过程，将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。

2、缺点

（1）建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，例如很多组成部分都不相同，不适合使用建造者模式，因此其使用范围受到一定的限制。

（2）如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大，增加系统的理解难度和运行成本。

四、建造者模式的使用场景

1、需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个成员属性。

2、需要生成的产品对象的属性相互依赖，需要指定其生成顺序。

3、对象的创建过程独立于创建该对象的类。

在建造者模式中通过引入指挥者类，将创建过程封装在指挥者类中，而不在建造者类和客户类中。

4、隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。

五、代码实例

1、产品类House 

package designMode.advance.builder;

public class House {
    private String baise;
    private String wall;
    private String roofed;
    public String getBaise() {
        return baise;
    }
    public void setBaise(String baise) {
        this.baise = baise;
    }
    public String getWall() {
        return wall;
    }
    public void setWall(String wall) {
        this.wall = wall;
    }
    public String getRoofed() {
        return roofed;
    }
    public void setRoofed(String roofed) {
        this.roofed = roofed;
    }
}

2、抽象建造者HouseBuilder 

package designMode.advance.builder;

public abstract class HouseBuilder {
    protected House house = new House();
    //将建造的流程写好, 抽象的方法
    public abstract void buildBasic();
    public abstract void buildWalls();
    public abstract void roofed();
    //建造房子好， 将产品(房子) 返回
    public House buildHouse() {
        return house;
    }
}

3、具体建造者

（1）CommonHouse 

package designMode.advance.builder;

public class CommonHouse extends HouseBuilder {
    @Override
    public void buildBasic() {
        System.out.println(" 普通房子打地基5米 ");
    }

    @Override
    public void buildWalls() {
        System.out.println(" 普通房子砌墙10cm ");
    }

    @Override
    public void roofed() {
        System.out.println(" 普通房子屋顶 ");
    }
}

（2）HighBuilding 

package designMode.advance.builder;

public class HighBuilding extends HouseBuilder {
    @Override
    public void buildBasic() {
        System.out.println(" 高楼的打地基100米 ");
    }

    @Override
    public void buildWalls() {
        System.out.println(" 高楼的砌墙20cm ");
    }

    @Override
    public void roofed() {
        System.out.println(" 高楼的透明屋顶 ");
    }
}

4、指挥者HouseDirector 

package designMode.advance.builder;

public class HouseDirector {
    HouseBuilder houseBuilder = null;

    //构造器传入 houseBuilder
    public HouseDirector(HouseBuilder houseBuilder) {
        this.houseBuilder = houseBuilder;
    }

    //通过setter 传入 houseBuilder
    public void setHouseBuilder(HouseBuilder houseBuilder) {
        this.houseBuilder = houseBuilder;
    }

    //如何处理建造房子的流程，交给指挥者
    public House constructHouse() {
        houseBuilder.buildBasic();
        houseBuilder.buildWalls();
        houseBuilder.roofed();
        return houseBuilder.buildHouse();
    }
}

5、测试类

package designMode.advance.builder;

public class Client {
    public static void main(String[] args) {
        //盖普通房子
        CommonHouse commonHouse = new CommonHouse();
        //准备创建房子的指挥者
        HouseDirector houseDirector = new HouseDirector(commonHouse);
        //完成盖房子，返回产品(普通房子)
        House house = houseDirector.constructHouse();

        System.out.println("--------------------------");
        //盖高楼
        HighBuilding highBuilding = new HighBuilding();
        //重置建造者
        houseDirector.setHouseBuilder(highBuilding);
        //完成盖房子，返回产品(高楼)
        houseDirector.constructHouse();
    }
}

6、控制台输出

六、建造者模式在SpringMVC中的实现

1、在springMVC中，我们就可以看到建造者模式的身影。

springMVC在构建UriComponents的内容时，就用到了建造者模式，我们先来看看UriComponents这个类是提供了哪些Components

public abstract class UriComponents implements Serializable {

    private static final String DEFAULT_ENCODING = "UTF-8";

    // 用于分割uri的正则表达式，下面会说到
    private static final Pattern NAMES_PATTERN = Pattern.compile("\\{([^/]+?)\\}");


    private final String scheme;

    private final String fragment;


    protected UriComponents(String scheme, String fragment) {
        this.scheme = scheme;
        this.fragment = fragment;
    }


    // 多个Components对应的getter方法

    /**
     * 返回URL的scheme.
     */
    public final String getScheme() {
        return this.scheme;
    }

    /**
     * 返回URL的fragment.
     */
    public final String getFragment() {
        return this.fragment;
    }

    /**
     * 返回URL的schemeSpecificPar
     */
    public abstract String getSchemeSpecificPart();

    /**
     * 返回userInfo
     */
    public abstract String getUserInfo();

    /**
     * 返回URL的host
     */
    public abstract String getHost();

    /**
     * 返回URL的port
     */
    public abstract int getPort();

    /**
     * 返回URL的path
     */
    public abstract String getPath();

    /**
     * 返回URL的path部分的集合
     */
    public abstract List<String> getPathSegments();

    /**
     * 返回URL的query部分
     */
    public abstract String getQuery();

    /**
     * 返回URL的query参数map
     */
    public abstract MultiValueMap<String, String> getQueryParams();


    /**
     * 将URL的components用特定的编码规则编码并返回，默认为utf-8
     */
    public final UriComponents encode() {
        try {
            return encode(DEFAULT_ENCODING);
        }
        catch (UnsupportedEncodingException ex) {
            // should not occur
            throw new IllegalStateException(ex);
        }
    }

    /**
     * 编码的抽象方法，传入相应的编码规则
     */
    public abstract UriComponents encode(String encoding) throws UnsupportedEncodingException;

    /**
     * 将URL中的模板参数换成对应的值
     */
    public final UriComponents expand(Map<String, ?> uriVariables) {
        Assert.notNull(uriVariables, "'uriVariables' must not be null");
        return expandInternal(new MapTemplateVariables(uriVariables));
    }

    /**
     * 将URL中的模板参数换成对应的值，输入为数组
     */
    public final UriComponents expand(Object... uriVariableValues) {
        Assert.notNull(uriVariableValues, "'uriVariableValues' must not be null");
        return expandInternal(new VarArgsTemplateVariables(uriVariableValues));
    }

    /**
     * 将URL中的模板参数换成对应的值，输入为UriTemplateVariables
     */
    public final UriComponents expand(UriTemplateVariables uriVariables) {
        Assert.notNull(uriVariables, "'uriVariables' must not be null");
        return expandInternal(uriVariables);
    }

    /**
     * 将URL中的模板参数换成对应的值的最终的实现方法
     */
    abstract UriComponents expandInternal(UriTemplateVariables uriVariables);

    /**
     * 处理URL
     */
    public abstract UriComponents normalize();

    /**
     * 返回URL的string
     */
    public abstract String toUriString();

    /**
     * 返回URI格式的方法
     */
    public abstract URI toUri();

    @Override
    public final String toString() {
        return toUriString();
    }

    /**
     * 将这些Components的值赋给其builder类
     */
    protected abstract void copyToUriComponentsBuilder(UriComponentsBuilder builder);

上面的代码不包括UriComponents类下其余的静态辅助方法，单单从此类的包含多种components中，就可以看出UriComponents的复杂程度。这些components大都对应了url的某个部分，能帮助springMVC对请求的url内容进行识别。springMVC就是通过将uri构建成这个类，再对uri进行处理的。

2、UriComponentsBuilder

那么springMVC究竟是如何让请求的uri生成相应的UriComponents类呢？就要看看UriComponentsBuilder这个类了。
首先看看它的两个构造函数：

/**
 * 默认构造方法，其中path的构造类为CompositePathComponentBuilder，它为UriComponentsBuilder的内部静态类，主要实现对url的path部分进行构造。
 */
protected UriComponentsBuilder() {
    this.pathBuilder = new CompositePathComponentBuilder();
}

/**
 * 创建一个传入UriComponentsBuilder类的深拷贝对象
 */
protected UriComponentsBuilder(UriComponentsBuilder other) {
    this.scheme = other.scheme;
    this.ssp = other.ssp;
    this.userInfo = other.userInfo;
    this.host = other.host;
    this.port = other.port;
    this.pathBuilder = other.pathBuilder.cloneBuilder();
    this.queryParams.putAll(other.queryParams);
    this.fragment = other.fragment;
}

由于url的path部分是比较复杂的，这边springMVC用了内部类的方式，为path单独加了两个builder类，分别是CompositePathComponentBuilder、FullPathComponentBuilder，这里就不扩展来说了。看完了UriComponentsBuilder的构造方法，我们来看它是如何将给定的uri生成为相应的UriComponents的。这里就从比较容易理解的fromUriString方法入手吧：

// 静态方法，从uri的字符串中获得uri的各种要素
public static UriComponentsBuilder fromUriString(String uri) {
    Assert.notNull(uri, "URI must not be null");
    // 利用正则表达式，获得uri的各个组成部分
    Matcher matcher = URI_PATTERN.matcher(uri);
    if (matcher.matches()) {
        UriComponentsBuilder builder = new UriComponentsBuilder();
        // 获得对应要素的字符串
        String scheme = matcher.group(2);
        String userInfo = matcher.group(5);
        String host = matcher.group(6);
        String port = matcher.group(8);
        String path = matcher.group(9);
        String query = matcher.group(11);
        String fragment = matcher.group(13);
        // uri是否透明的标志位
        boolean opaque = false;
        // uri存在scheme且后面不跟:/则为不透明uri 
        例如mailto:[email protected]
        if (StringUtils.hasLength(scheme)) {
            String rest = uri.substring(scheme.length());
            if (!rest.startsWith(":/")) {
                opaque = true;
            }
        }
        builder.scheme(scheme);
        // 如果为不透明uri，则具备ssp，需要设置ssp
        if (opaque) {
            String ssp = uri.substring(scheme.length()).substring(1);
            if (StringUtils.hasLength(fragment)) {
                ssp = ssp.substring(0, ssp.length() - (fragment.length() + 1));
            }
            builder.schemeSpecificPart(ssp);
        }
        // 如果为绝对uri（通常意义上的uri），则设置各个component
        else {
            builder.userInfo(userInfo);
            builder.host(host);
            if (StringUtils.hasLength(port)) {
                builder.port(port);
            }
            builder.path(path);
            builder.query(query);
        }
        if (StringUtils.hasText(fragment)) {
            builder.fragment(fragment);
        }
        return builder;
    }
    // 传入uri格式不对，抛出异常
    else {
        throw new IllegalArgumentException("[" + uri + "] is not a valid URI");
    }
}

从上面的方法中，我们可以看到，UriComponentsBuilder从一个uri的字符串中，通过正则匹配的方式，获取到不同Components的信息并赋值。UriComponentsBuilder除了fromUriString这一种构建方法外，还提供fromUri，fromHttpUrl，fromHttpRequest，fromOriginHeader等好几种构建的方法，感兴趣的小伙伴可以自己去看。
那么在通过各种构建后，获取到了对应的Components信息，最后的一步，也是最重要的一步，build，将会返回我们需要的UriComponents类。UriComponentsBuilder提供了两类build方法，我们主要看默认的build方法：

/**
 * 默认的build方法
 */
public UriComponents build() {
    return build(false);
}

/**
 * 具体的build实现方法，它通过ssp是否为空，判断构造的uri属于相对uri还是绝对uri，生成OpaqueUriComponents类（相对）或HierarchicalUriComponents类（绝对），它们都为UriComponents的子类
 */
public UriComponents build(boolean encoded) {
    if (this.ssp != null) {
        return new OpaqueUriComponents(this.scheme, this.ssp, this.fragment);
    }
    else {
        // 调用pathBuilder的build方法，构造对应的path
        return new HierarchicalUriComponents(this.scheme, this.userInfo, this.host, this.port,
                this.pathBuilder.build(), this.queryParams, this.fragment, encoded, true);
    }
}

可以看到，UriComponentsBuilder的build方法很简单，就是返回相应的UriComponents类。其中，在构造HierarchicalUriComponents时，还调用了pathBuilder的build方法生成uri对应的path，这里不继续展开了。

3、总结

从springMVC通过UriComponentsBuilder构建UriComponents类的整个源码与流程中，我们可以窥见建造者模式在其中发挥的巨大作用。
它通过builder类，提供了多种UriComponents的初始化方式，并能根据不同情况，返回不同的UriComponents子类。充分的将UriComponents类本身与它的构造过程解耦合。
试想一下，如果不使用建造者模式，而是将大量的初始化方法直接塞到UriComponents类或其子类中，它的代码将变得非常庞大和冗余。而建造者模式可以帮助我们很好的解决这一问题。
所以，如果我们在写代码时，某个复杂的类有多种初始化形式或者初始化过程及其繁琐，并且还对应多个复杂的子类（总之就是构造起来很麻烦），我们就可以用建造者模式，将该类和该类的构造过程解耦哦！