设计模式之建造者

233 阅读8分钟

简介

建造者模式(Builder Pattern)使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。

一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。

传统构建复杂对象的优缺点:

  1. 优点是比较好理解,简单易操作。
  2. 设计的程序结构,过于简单,没有设计缓存层对象,程序的扩展和维护不好.也就 是说,这种设计方案,把产品(即:房子)和创建产品的过程(即:建房子流程)封 装在一起,耦合性增强了。
  3. 解决方案:将产品和产品建造过程解耦=>建造者模式.

what

通常,对象构造的细节(例如,实例化和初始化组成对象的组件)通常作为对象构造函数的一部分保留在对象内。这种设计将对象的构建过程与组成对象的组件紧密地联系在一起。只要正在构造的对象简单且对象的构造过程是确定的,并且始终产生相同的对象表示,则此方法适用。

但是,当要创建的对象很复杂并且构成对象创建过程的一系列步骤可以以不同的方式执行,从而产生对象的不同表示形式时,此设计可能无效。因为构造过程的不同实现都保存在对象中,所以对象可能变得笨重(构造膨胀)并且模块化程度降低。随后,添加新的实现或对现有实现进行更改需要对现有代码进行更改。

使用Builder模式,可以更有效地设计构造此类对象的过程。 Builder模式建议将构造逻辑从对象类中移到一个单独的类中,称为Builder类。可以有多个这样的构建器类,每种构建器类对于构建对象的一系列步骤都具有不同的实现。每个构建器实现都会导致对象的不同表示形式。

how

  1. 构建器模式的目的是将复杂对象的构造与实现分离,以便相同的构造过程可以创建不同的实例。 这种类型的分离减少了对象的大小。设计结果是更加模块化,每个实现包含在不同的构建器对象中。 添加一个新的实现(即,添加一个新的构建器)变得更容易。对象构造过程变得独立于组成对象的组件。这提供了对对象构造过程的更多控制。
  2. 就实现而言,构建过程中的每个不同步骤都可以被声明为由不同的具体构建者实现的公共接口的方法。
  3. 客户端对象可以创建一个具体构建器的实例,并调用一组方法来构造最终对象的不同部分。这种方法要求每个客户端对象都知道构造逻辑。每当构造逻辑发生更改时,所有客户端对象都需要相应地进行修改。
  4. 构建器模式引入了解决此问题的另一种级别的分离。与让客户端对象直接调用不同的构建器方法不同, 构建器模式建议使用一个称为Director的专用对象,它负责调用构建最终对象所需的不同构建器方法。 不同的客户端对象可以使用Director对象来创建所需的对象。一旦对象被构造,客户端对象就可以直接向构建器请求完全构造好的对象。 为了简化这个过程,可以在公共构建器接口中声明一个新的方法getObject,由不同的具体构建器实现。
  5. 新的设计消除了客户端对象处理构成对象构造过程的方法的需要,并封装了如何从客户端构造对象的细节。

建造者模式的四个角色

  1. Product(产品角色):一个具体的产品对象。
  2. Builder (抽象建造者) :创建- - 个Product对象的各个部件指定的接口。
  3. ConcreteBuilder ( 具体建造者) :实现接口,构建和装配各个部件。
  4. Director (指挥者) :构建-个使用Builder接口的对象。它主要是用于创建一个 复杂的对象。 它主要有两个作用 一是:隔离了客户与对象的生产过程, 二是:负责控制产品对象的生产过程。
public interface Item {
    /**
     * 食品名称
     * @return
     */
    String name();

    /**
     * 包装
     * @return
     */
    Packing packing();

    /**
     * 价格
     * @return
     */
    float price();
}
public interface Packing {
    /**
     * 包装方法
     * @return
     */
    String pack();
}

public class Bottle implements Packing {
    /**
     * 包装方法
     *
     * @return
     */
    @Override
    public String pack() {
        return "bottle";
    }
}

/**
 * 汉堡抽象类
 * @author Evan
 * @Date 2018/9/3
 */
public abstract class Burger implements Item {
    /**
     * 包装
     *
     * @return
     */
    @Override
    public Packing packing() {
        return new Wrapper();
    }

    /**
     * 价格
     *
     * @return
     */
    @Override
    public abstract float price() ;
}

public class ChickenBurger extends Burger {
    /**
     * 食品名称
     *
     * @return
     */
    @Override
    public String name() {
        return "Chicken Burger";
    }

    /**
     * 价格
     *
     * @return
     */
    @Override
    public float price() {
        return 50.5f;
    }
}
public class Coke extends ColdDrink {
    /**
     * 食品名称
     *
     * @return
     */
    @Override
    public String name() {
        return "Coke";
    }

    /**
     * 价格
     *
     * @return
     */
    @Override
    public float price() {
        return 30.0f;
    }
}

public abstract class ColdDrink implements Item {
    /**
     * 包装
     *
     * @return
     */
    @Override
    public Packing packing() {
        return new Bottle();
    }

    /**
     * 价格
     *
     * @return
     */
    @Override
    public abstract float price();
}

public class Meal {
    /**
     * 套餐种类
     */
    private List<Item> items = new ArrayList<>();

    /**
     * 添加食物
     *
     * @param item
     */
    public void addItem(Item item) {
        items.add(item);
    }

    /**
     * 计算总消费
     * @return
     */
    public float cost(){
        float cost=0f;
        for (Item item : items) {
            cost +=item.price();
        }
        return cost;
    }

    /**
     * 展示套餐种类信息
     */
    public void showItems(){
        for (Item item : items) {
            System.out.print("Item : "+item.name());
            System.out.print(", Packing : "+item.packing().pack());
            System.out.println(", Price : "+item.price());
        }
    }
}
public class MealBulider {
    /**
     * 创建素食套餐
     * @return
     */
    public Meal prepareVegMeal(){
        Meal meal =new Meal();
        meal.addItem(new VegBurger());
        meal.addItem(new Coke());
        return meal;
    }

    /**
     * 创建肉食套餐
     * @return
     */
    public Meal prepareNonVegMeal(){
        Meal meal =new Meal();
        meal.addItem(new ChickenBurger());
        meal.addItem(new Pepsi());
        return meal;
    }
}

public class Pepsi extends ColdDrink {
    /**
     * 食品名称
     *
     * @return
     */
    @Override
    public String name() {
        return "Pepsi";
    }

    /**
     * 价格
     *
     * @return
     */
    @Override
    public float price() {
        return 35.0f;
    }
}
public class VegBurger extends Burger {
    /**
     * 食品名称
     *
     * @return
     */
    @Override
    public String name() {
        return "Veg Burger";
    }

    /**
     * 价格
     *
     * @return
     */
    @Override
    public float price() {
        return 2.5f;
    }
}

public class Wrapper implements Packing {
    /**
     * 包装方法
     *
     * @return
     */
    @Override
    public String pack() {
        return "wrapper";
    }
}

使用Lombok的注解@Builder的方式,可以实现建造者模式。

框架中的建造模式

● 建造模式在JDK源码分析,StringBuilder类。

  1. Appendable接口定义了多个append方法(抽象方法),即Appendable为抽象建 造者,定义了抽象方法
  2. AbstractStringBuilder实现了Appendable接口方法,这里的 AbstractStringBuilder已经是建造者,只是不能实例化
  3. StringBuilder即充当了指挥者角色,同时充当了具体的建造者,建造方法的 实现是由AbstractStringBuilder完成,而StringBuilder继承了 AbstractStringBuilder

● 建造模式在Spring源码分析.

  1. 从springMVC通过UriComponentsBuilder构建UriComponents类的整个源码与流程中,我们可以窥见建造者模式在其中发挥的巨大作用。

  2. 它通过builder类,提供了多种UriComponents的初始化方式,并能根据不同情况,返回不同的UriComponents子类。充分的将UriComponents类本身与它的构造过程解耦合。

  3. 试想一下,如果不使用建造者模式,而是将大量的初始化方法直接塞到UriComponents类或其子类中,它的代码将变得非常庞大和冗余。而建造者模式可以帮助我们很好的解决这一问题。

● 建造模式在mybatis源码分析. SqlSessionFactoryBuilder,使用XMLConfigBuilder解析mybatis配置文件,装配到Configuration中。将配置文件中的Mapper添加到Configuration mapperRegistry实现注册。

why

优点:

  1. 建造者独立,易扩展。
  2. 便于控制细节风险。

缺点:

  1. 产品必须有共同点,范围有限制。
  2. 如内部变化复杂,会有很多的建造类。

when

何时使用:

  1. 去肯德基,汉堡、可乐、薯条、炸鸡翅等是不变的,而其组合是经常变化的,生成出所谓的"套餐"。
  2. JAVA 中的 StringBuilder。

使用场景:

  1. 需要生成的对象具有复杂的内部结构。
  2. 需要生成的对象内部属性本身相互依赖。

小结

  1. 客户端(使用程序)不必知道产品内部组成的细节,将产品本身与产品的创建过程解 耦,使得相同的创建过程可以创建不同的产品对象
  2. 每一个具体建造者都相对独立,而与其他的具体建造者无关,因此可以很方便地替 换具体建造者或增加新的具体建造者,用户 使用不同的具体建造者即可得到不同 的产品对象
  3. 可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法 中,使得创建过程更加清晰,也更方便使用程序来控制创建过程
  4. 增加新的具体建造者无须修改原有类库的代码,指挥者类针对抽象建造者类编程, 系统扩展方便,符合“开闭原则”
  5. 建造者模式所创建的产品一般具有较多的共同点,其组成部分相似,如果产品之间 的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制。
  6. 如果产品的内部变化复杂,可能会导致需要定义很多具体建造者类来实现这种变化, 导致系统变得很庞大,因此在这种情况下,要考虑是否选择建造者模式.
  7. 抽象工厂模式VS建造者模式 抽象工厂模式实现对产品家族的创建,一个产品家族是这样的一系列产品:具有不 同分类维度的产品组合,采用抽象工厂模式不需要关心构建过程,只关心什么产品 由什么工厂生产即可。而建造者模式则是要求按照指定的蓝图建造产品,它的主要 目的是通过组装零配件而产生一个新产品

本文来自公众号