建造者模式
建造者UML.png
class Goods{
private String A;
private String B;
private String C;
//setter and getter
// toString
}
最终得到的商品类，A，B，C假想成商品的重要组成部分
abstract class GoodsBuild{
protected Goods goods = new Goods();
public abstract buildA();
public abstract buildB();
public abstract buildC();
public Goods makeGoods(){
return goods;
}
}
抽象建造者
class AGoodsBuild extends GoodsBuild{
public void buildA(){
goods.setA("A商品的第一个属性");
}
public void buildB(){
goods.setA("A商品的第二个属性");
}
public void buildC(){
goods.setA("A商品的第三个属性");
}
}
A商品的构造器
class BGoodsBuild extends GoodsBuild{
public void buildA(){
goods.setA("B商品的第一个属性");
}
public void buildB(){
goods.setA("B商品的第二个属性");
}
public void buildC(){
goods.setA("B商品的第三个属性");
}
}
B商品的构造器
class GoodsController{
public Goods getGoods(GoodsBuild gb){
gb.buildA();
gb.buildB();
gb.buildC();
return gb.makeGoods();
}
}
商品控制器，用来拿商品的
class Client{
public static void main(String args[]){
GoodBuild gb = new AGoodsBuild();
GoodsController controller = new GoodsController();
Goods goods = controller.getGoods(gb);
}
}
客户端，一个商品控制器传入一个具体的商品构造器即可获得对于属性的商品goods。
优点：
- 在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解 耦，使得相同的创建过程可以创建不同的产品对象。
- 每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体 建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。由于 指挥者类针对抽象建造者编程，增加新的具体建造者无须修改原有类库的代码，系统扩展方 便，符合“开闭原则”
- 可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得 创建过程更加清晰，也更方便使用程序来控制创建过程。
缺点
- 建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异 性很大，例如很多组成部分都不相同，不适合使用建造者模式，因此其使用范围受到一定的 限制。
- 如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致 系统变得很庞大，增加系统的理解难度和运行成本。
