当一个产品的构建过程是固定且复杂多变的，则可以将该产品的构建过程抽象出来。

从一个简单的例子出发

比如：组装一台电脑，你一定需要有CPU、主板、内存、硬盘以及IO外设。而每个部分你都可以选择不同的类型：CPU可以是Arm或者Intel，内存可以是台电的或是三星的等等。

这样的话，如果将构建电脑的过程抽象出来，就可以如下表示：

public abstract class ComputerBuilder{
    public abstract void buildCPU();
    public abstract void buildMemory(); 
    public abstract void buildIO();
    public abstract Product getProduct();
}

而产品可以简单表示为：

public class Computer {
    String memory;
    String IO;
    String CPU;
    @Override
    public String toString() {
        // TODO Auto-generated method stub
        return "memory:"+memory+"\n"+"IO:"+IO+"\n"+"CPU:"+CPU;
    }
}

这个时候如果Dell需要生产一台电脑就会这样做：

public class DellComputerBuilder extends ComputerBuilder{
    
    private Computer DellComputer = new Computer();
    
    @Override
    public void buildCPU() {
        // TODO Auto-generated method stub
        DellComputer.CPU = "dellCPU";
    }

    @Override
    public void buildMemory() {
        // TODO Auto-generated method stub
        DellComputer.IO = "dellIO";
    }

    @Override
    public void buildIO() {
        // TODO Auto-generated method stub
        DellComputer.memory = "dellMemory";
    }

    @Override
    public Computer getProduct() {
        // TODO Auto-generated method stub
        buildCPU();
        buildIO();
        buildMemory();
        return DellComputer;
    }
    
}

最后经销商director将负责把产品卖出：

public class Director {
    private ComputerBuilder computerBuilder;
    public Director(ComputerBuilder cb) {
        this.computerBuilder = cb;
    }
    public Computer getComputer() {
        return computerBuilder.getProduct();
    }
}

这四个类的关系大致如下：

image

与工厂模式（模板工厂、抽象工厂）的区别和联系

我们可以看到整个建造者模式是一个特别强调产品构建过程的设计模式，而工厂模式则更加强调了产品的种类。

事实上，上面的例子我特地给出了DellComputer，这说明Computer完全可以作为一个抽象产品类出现，从而满足不同类型的builder。这些builder完全可以是联想、华硕等等。

而在经销商看来，只要你的产品没有缺失（都含有CPU、Memory、IO），那么经销商就完全不必去关心电脑怎么组装的，也不用关心是哪个厂家生产的。经销商只需要告诉客户一件事，那就是我卖的是Computer。而客户需要哪种Computer，只需要告诉经销商即可。