Skip to content

7. 建造者模式

Landy.Liu edited this page May 18, 2019 · 1 revision

7.1 概念

将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示

7.2 作用

在用户不知道对象的建造过程和细节的情况下就可以直接创建复杂的对象。

  1. 用户只需要给出指定复杂对象的类型和内容;
  2. 建造者模式负责按顺序创建复杂对象(把内部的建造过程和细节隐藏起来)

7.3 解决的问题

  1. 方便用户创建复杂的对象(不需要知道实现过程)
  2. 代码复用性 & 封装性(将对象构建过程和细节进行封装 & 复用)

7.4 实现步骤

  1. 指挥者(Director)直接和客户(Client)进行需求沟通;
  2. 沟通后指挥者将客户创建产品的需求划分为各个部件的建造请求(Builder);
  3. 将各个部件的建造请求委派到具体的建造者(ConcreteBuilder);
  4. 各个具体建造者负责进行产品部件的构建;
  5. 最终构建成具体产品(Product)。

7.5 优缺点

在全面解析完后,我来分析下其优缺点:

7.5.1 优点

  1. 易于解耦 将产品本身与产品创建过程进行解耦,可以使用相同的创建过程来得到不同的产品。也就说细节依赖抽象。
  2. 易于精确控制对象的创建 将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰
  3. 易于拓展 增加新的具体建造者无需修改原有类库的代码,易于拓展,符合“开闭原则“。 每一个具体建造者都相对独立,而与其他的具体建造者无关,因此可以很方便地替换具体建造者或增加新的具体建造者,用户使用不同的具体建造者即可得到不同的产品对象。

7.5.2 缺点

建造者模式所创建的产品一般具有较多的共同点,其组成部分相似;如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制。 如果产品的内部变化复杂,可能会导致需要定义很多具体建造者类来实现这种变化,导致系统变得很庞大。

7.6 应用场景

  1. 需要生成的产品对象有复杂的内部结构,这些产品对象具备共性;
  2. 隔离复杂对象的创建和使用,并使得相同的创建过程可以创建不同的产品。

7.7 demo

实际项目中的一个案例:系统集成中,需要把客户传过来的数据进行封装处理,然后统一交给后端系统处理,然后集成到自己的业务系统中。 假设集成过来的数据有以下几部分组成:

  1. 用户信息(user_profile)
  2. 订单计划信息(plan)
  3. 订单信息(order)
  4. 订单成员信息(member)
  5. ...

由于实际业务系统太过复杂,这边就简化为以上四个部分,实际业务中Builder中的方法都有相应的返回类型,这里直接简单些为void,然后实现为控制台输出。

具体实现参见代码部分即可。