建造者模式

 

http://blog.51cto.com/craftsman001/1662488

https://blog.csdn.net/itachi85/article/details/50644745

建造者模式需要四大角色：

（1）目标者类Target：有n个属性。不能多变。

（2）抽象建造者接口Builder：关联目标类Target，对应n个属性的n个建造方法和一个返回目标类对象的方法。返回值依赖于目标类Target。

（3）具体建造者类ConcreteBuilder：实现抽象建造者接口，关联目标类Target。

（4）指导者类Director：参数依赖建造者类，按照一定顺序调用建造者类的方法，并返回目标类对象。返回值依赖目标类Target，参数依赖抽象建造者模式。

（5）客户端类Client：通过传入建造者类创建指导者类来创建目标类。

 

1.建造者模式简介

定义

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

简介

建造者模式（builder）是创建一个复杂对象的创建型模式，将构建复杂对象的过程和它的部件解耦，使得构建过程和部件的表示分离开来。 
例如我们要DIY一个台式机电脑，我们找到DIY商家，我们可以要求这台电脑的cpu或者主板或者其他的部件都是什么牌子的什么配置的，这些部件是我们可以根据我们的需求来变化的，但是这些部件组装成电脑的过程是一样的，我们不需要知道这些部件是怎样组装成电脑的，我们只需要提供部件的牌子和配置就可以了。对于这种情况我们就可以采用建造者模式，将部件和组装过程分离，使得构建过程和部件都可以自由拓展，两者之间的耦合也降到最低。

      有些情况下，一个对象会有一些重要的性质，在它们没有恰当的值之前，对象不能作为一个完整的产品使用。比如，一个电子邮件有发件人地址、收件人地址、主题、内容、附录等部分，而在最起码的收件人地址得到赋值之前，这个电子邮件不能发送。

 

　　有些情况下，一个对象的一些性质必须按照某个顺序赋值才有意义。在某个性质没有赋值之前，另一个性质则无法赋值。这些情况使得性质本身的建造涉及到复杂的商业逻辑。这时候，此对象相当于一个有待建造的产品，而对象的这些性质相当于产品的零件，建造产品的过程是建造零件的过程。由于建造零件的过程很复杂，因此，这些零件的建造过程往往被“外部化”到另一个称做建造者的对象里，建造者对象返还给客户端的是一个全部零件都建造完毕的产品对象。

 

　　建造模式利用一个导演者对象和具体建造者对象一个个地建造出所有的零件，从而建造出完整的产品对象。建造者模式将产品的结构和产品的零件的建造过程对客户端隐藏起来，把对建造过程进行指挥的责任和具体建造者零件的责任分割开来，达到责任划分和封装的目的。

在这个示意性的系统里，最终产品Product只有两个零件，即part1和part2。相应的建造方法也有两个：buildPart1()和buildPart2()、同时可以看出本模式涉及到四个角色，它们分别是：

　　抽象建造者（Builder）角色：给 出一个抽象接口，以规范产品对象的各个组成成分的建造。一般而言，此接口独立于应用程序的商业逻辑。模式中直接创建产品对象的是具体建造者 (ConcreteBuilder)角色。具体建造者类必须实现这个接口所要求的两种方法：一种是建造方法(buildPart1和 buildPart2)，另一种是返还结构方法(retrieveResult)。一般来说，产品所包含的零件数目与建造方法的数目相符。换言之，有多少 零件，就有多少相应的建造方法。

　　具体建造者（ConcreteBuilder）角色：担任这个角色的是与应用程序紧密相关的一些类，它们在应用程序调用下创建产品的实例。这个角色要完成的任务包括：1.实现抽象建造者Builder所声明的接口，给出一步一步地完成创建产品实例的操作。2.在建造过程完成后，提供产品的实例。

　　导演者（Director）角色：担任这个角色的类调用具体建造者角色以创建产品对象。应当指出的是，导演者角色并没有产品类的具体知识，真正拥有产品类的具体知识的是具体建造者角色。

　　产品（Product）角色：产品便是建造中的复杂对象。一般来说，一个系统中会有多于一个的产品类，而且这些产品类并不一定有共同的接口，而完全可以是不相关联的。

　　

　　导演者角色是与客户端打交道的角色。导演者将客户端创建产品的请求划分为对各个零件的建造请求，再将这些请求委派给具体建造者角色。具体建造者角色是做具体建造工作的，但是却不为客户端所知。

　　一般来说，每有一个产品类，就有一个相应的具体建造者类。这些产品应当有一样数目的零件，而每有一个零件就相应地在所有的建造者角色里有一个建造方法。

 

建造者模式结构图

• Dirextor: 指挥者类，用于统一组装流程
• Builder：抽象Builder类，规范产品的组建，一般是由子类实现。
• ConcreteBulider: 抽象Builder类的实现类，实现抽象Builder类定义的所有方法，并且返回一个组建好的对象
• Product: 产品类

2.建造者模式简单实现

这里我们就用DIY组装电脑的例子来实现一下建造者模式。

创建产品类

我要组装一台电脑，电脑被抽象为Computer类，它有三个部件:CPU 、主板和内存。并在里面提供了三个方法分别用来设置CPU 、主板和内存：

public class Computer {
    private String mCpu;
    private String mMainboard;
    private String mRam;

    public void setmCpu(String mCpu) {
        this.mCpu = mCpu;
    }

    public void setmMainboard(String mMainboard) {
        this.mMainboard = mMainboard;
    }

    public void setmRam(String mRam) {
        this.mRam = mRam;
    }
}

创建Builder类规范产品的组建

商家组装电脑有一套组装方法的模版，就是一个抽象的Builder类,里面提供了安装CPU、主板和内存的方法，以及组装成电脑的create方法：

public abstract class Builder {
    public abstract void buildCpu(String cpu);
    public abstract void buildMainboard(String mainboard);
    public abstract void buildRam(String ram);
    public abstract Computer create();
}

商家实现了抽象的Builder类，MoonComputerBuilder类用于组装电脑：

public class MoonComputerBuilder extends Builder {
    private Computer mComputer = new Computer();
    @Override
    public void buildCpu(String cpu) {
        mComputer.setmCpu(cpu);
    }

    @Override
    public void buildMainboard(String mainboard) {
        mComputer.setmMainboard(mainboard);
    }

    @Override
    public void buildRam(String ram) {
        mComputer.setmRam(ram);
    }

    @Override
    public Computer create() {
        return mComputer;
    }
}

用Dirextor指挥者类来统一组装过程

商家的指挥者类用来规范组装电脑的流程规范，先安装主板，再安装CPU，最后安装内存并组装成电脑：

public class Direcror {
    Builder mBuild=null;
    public Direcror(Builder build){
        this.mBuild=build;
    }
    public Computer CreateComputer(String cpu,String mainboard,String ram){
        //规范建造流程
       this.mBuild.buildMainboard(mainboard);
       this.mBuild.buildCpu(cpu);
       this.mBuild.buildRam(ram);
       return mBuild.create();
    }
}

客户端调用指挥者类

最后商家用指挥者类组装电脑。我们只需要提供我们想要的CPU，主板和内存就可以了，至于商家怎样组装的电脑我们无需知道。

public class CreatComputer {
    public static void main(String[]args){
        Builder mBuilder=new MoonComputerBuilder();
        Direcror mDirecror=new Direcror(mBuilder);
        //组装电脑
        mDirecror.CreateComputer("i7-6700","华擎玩家至尊","三星DDR4");
    }
}

3.使用建造者模式的场景和优缺点

使用场景

• 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
• 相同的方法，不同的执行顺序，产生不同的事件结果时。
• 多个部件或零件,都可以装配到一个对象中，但是产生的运行结果又不相同时。
• 产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能。
• 创建一些复杂的对象时，这些对象的内部组成构件间的建造顺序是稳定的，但是对象的内部组成构件面临着复杂的变化。

优缺点

优点：

• 使用建造者模式可以使客户端不必知道产品内部组成的细节。
• 具体的建造者类之间是相互独立的，容易扩展。
• 由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。

缺点：

• 产生多余的Build对象以及Dirextor类。

##########################################################################################

 

Builder模式可以称为建造者模式，它将一个复杂对象的构建和表示分离，同样的构建过程可以创建不同的表示 
适用场景： 
相同的方法，不同执行顺序，产生不同事件结果 
多个部件都可以装配到一个对象中，但产生的运行结果不相同 
产品类非常复杂或者产品类因为调用顺序不同而产生不同作用 
初始化一个对象时，参数过多，或者很多参数具有默认值 
 
用 builder 模式创建共享单车为例子，示例代码： 
没有贴出来的类请参考另外一篇文章 
产品类： 
public class Bike { 
private IFrame frame; 
private ISeat seat; 
private ITire tire; 
public IFrame getFrame() { 
return frame; 
} 
public void setFrame(IFrame frame) { 
this.frame = frame; 
} 
public ISeat getSeat() { 
return seat; 
} 
public void setSeat(ISeat seat) { 
this.seat = seat; 
} 
public ITire getTire() { 
return tire; 
} 
public void setTire(ITire tire) { 
this.tire = tire; 
} 
} 
Builder 类： 
// 抽象 builder 类 
public abstract class Builder { 
abstract void buildFrame(); 
abstract void buildSeat(); 
abstract void buildTire(); 
abstract Bike createBike(); 
} 
// 具体 builder 类 
public class MobikeBuilder extends Builder{ 
private Bike mBike = new Bike(); 
@Override 
void buildFrame() { 
mBike.setFrame(new AlloyFrame()); 
} 
@Override 
void buildSeat() { 
mBike.setSeat(new DermisSeat()); 
} 
@Override 
void buildTire() { 
mBike.setTire(new SolidTire()); 
} 
@Override 
Bike createBike() { 
return mBike; 
} 
} 
public class OfoBuilder extends Builder{ 
private Bike mBike = new Bike(); 
@Override 
void buildFrame() { 
mBike.setFrame(new CarbonFrame()); 
} 
@Override 
void buildSeat() { 
mBike.setSeat(new RubberSeat()); 
} 
@Override 
void buildTire() { 
mBike.setTire(new InflateTire()); 
} 
@Override 
Bike createBike() { 
return mBike; 
} 
} 
导演类： 
public class Director { 
private Builder mBuilder = null; 
public Director(Builder builder) { 
mBuilder = builder; 
} 
public Bike construct() { 
mBuilder.buildFrame(); 
mBuilder.buildSeat(); 
mBuilder.buildTire(); 
return mBuilder.createBike(); 
} 
}

 

使用方式： 
public class Click { 
public static void main(String[] args) { 
showBike(new OfoBuilder()); 
showBike(new MobikeBuilder()); 
} 
private void showBike(Builder builder) { 
Director director = new Director(builder); 
Bike bike = director.construct(); 
bike.getFrame().frame(); 
bike.getSeat().seat(); 
bike.getTire().tire(); 
} 
} 
上面示例是 Builder模式的常规用法，导演类 Director 在 Builder模式中具有很重要的作用，它用于指导具体构建者如何构建产品，控制调用先后次序，并向调用者返回完整的产品类，但是有些情况下需要简化系统结构，可以把Director和抽象建造者进行结合，示例代码： 
改造后的抽象建造者： 
public abstract class NewBuilder { 
abstract void buildFrame(); 
abstract void buildSeat(); 
abstract void buildTire(); 
abstract Bike createBike(); 
/** 
* 把导演类中的construct()方法合并到抽象建造者类中 
* 
* @return 具体产品对象 
*/ 
public Bike construct() { 
this.buildFrame(); 
this.buildSeat(); 
this.buildTire(); 
return this.createBike(); 
} 
} 
这样做确实简化了系统结构，但同时也加重了抽象建造者类的职责，也不是太符合单一职责原则，如果construct() 过于复杂，建议还是封装到 Director 中 
除了上面的用途外，还有另外一个常用的使用方式，就是当一个类构造器需要传入很多参数时，如果创建这个类的实例，代码可读性会非常差，而且很容易引入错误，此时就可以利用 builder模式进行重构，重构前示例代码： 
// 省略 getter 和 setter 方法 
public class Computer { 
private String cpu; 
private String screen; 
private String memory; 
private String mainboard; 
public Computer(String cpu, String screen, String memory, String mainboard) { 
this.cpu = cpu; 
this.screen = screen; 
this.memory = memory; 
this.mainboard = mainboard; 
} 
} 
public class NewComputer { 
private String cpu; 
private String screen; 
private String memory; 
private String mainboard; 
public NewComputer() { 
throw new RuntimeException(“can’t init”); 
} 
private NewComputer(Builder builder) { 
cpu = builder.cpu; 
screen = builder.screen; 
memory = builder.memory; 
mainboard = builder.mainboard; 
} 
public static final class Builder { 
private String cpu; 
private String screen; 
private String memory; 
private String mainboard; 
public Builder() {} 
public Builder cpu(String val) { 
cpu = val; 
return this; 
} 
public Builder screen(String val) { 
screen = val; 
return this; 
} 
public Builder memory(String val) { 
memory = val; 
return this; 
} 
public Builder mainboard(String val) { 
mainboard = val; 
return this; 
} 
public NewComputer build() {return new NewComputer(this);} 
} 
} 
客户端： 
public class Click { 
public static void main(String[] args) { 
// 非 Builder 模式 
Computer computer = new Computer(“cpu”, “screen”, “memory”, “mainboard”); 
// Builder 模式 
NewComputer newComputer = new NewComputer.Builder() 
.cpu(“cpu”) 
.screen(“screen”) 
.memory(“memory”) 
.mainboard(“mainboard”) 
.build(); 
} 
} 
上面的示例代码只是传入四个参数，如果参数是十四个甚至更多，builder 模式的优势将会更加明显，传递参数更加灵活，代码具有更高的可读性 
建造者模式与抽象工厂模式的比较: 
与抽象工厂模式相比，建造者模式返回一个组装好的完整产品，而抽象工厂模式返回一系列相关的产品，这些产品位于不同的产品等级结构，构成了一个产品族 
在抽象工厂模式中，客户端实例化工厂类，然后调用工厂方法获取所需产品对象，而在建造者模式中，客户端可以不直接调用建造者的相关方法，而是通过指挥者类来指导如何生成对象，包括对象的组装过程和建造步骤，它侧重于一步步构造一个复杂对象，返回一个完整的对象 
如果将抽象工厂模式看成汽车配件生产工厂，生产一个产品族的产品，那么建造者模式就是一个汽车组装工厂，通过对部件的组装可以返回一辆完整的汽车 
说了这么多 Builder模式的好处，再来看看它有什么缺点： 
Builder模式所创建的产品一般具有较多共同点，组成部分也相似，所以 Builder模式不适合创建差异性很大的产品类 
产品内部变化复杂，会导致需要定义很多具体建造者类实现变化，增加项目中类的数量，增加系统的理解难度和运行成本 。

################################################################################################

                                                                                       工厂方法模式和建造者模式异同

################################################################################################

 

工厂方法模式和建造者模式都属于对象创建类模式，都用来创建类的对象。但它们之间的区别还是比较明显的。

 

　　1、意图不同。

 

　　在工厂方法模式里，我们关注的是一个产品整体，如超人整体，无须关心产品的各部分是如何创建出来的；但在建造者模式中，一个具体产品的产生是依赖各个部件的产生以及装配顺序，它关注的是“由零件一步一步地组装出产品对象”。简单地说，工厂模式是一个对象创建的粗线条应用，建造者模式则是通过细线条勾勒出一个复杂对象，关注的是产品组成部分的创建过程。

 

　　2、产品的复杂度不同。

 

　　工厂方法模式创建的产品一般都是单一性质产品，如成年超人，都是一个模样，而建造者模式创建的则是一个复合产品，它由各个部件复合而成，部件不同产品对象当然不同。这不是说工厂方法模式创建的对象简单，而是指它们的粒度大小不同。一般来说，工厂方法模式的对象粒度比较粗，建造者模式的产品对象粒度比较细。
　　两者的区别有了，那在具体的应用中，我们该如何选择呢？是用工厂方法模式来创建对象，还是用建造者模式来创建对象，这完全取决于我们在做系统设计时的意图，如果需要详细关注一个产品部件的生产、安装步骤，则选择建造者，否则选择工厂方法模式。

##################################################################

 

3.1 优点

 

• 易于解耦 

  将产品本身与产品创建过程进行解耦，可以使用相同的创建过程来得到不同的产品。也就说细节依赖抽象。

• 易于精确控制对象的创建 

  将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰

• 易于拓展 

  增加新的具体建造者无需修改原有类库的代码，易于拓展，符合“开闭原则“。 

  每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。

 

3.2 缺点

 

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

• 如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。 

  ---

 

4. 应用场景

 

• 需要生成的产品对象有复杂的内部结构，这些产品对象具备共性；

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