设计模式2-建造者模式

引言

当遇到一个类中的参数非常多的时候,构造函数的定义会显得非常的冗长,可读性下降。并且这种时候,某些参数往往是可选而非每个对象都必须有的,因此当创建对象时,就容易夹杂很多无用的参数。这个时候,我们采用建造者模式是一种很好的选择。

业务背景

假设现在要设计某样食品的标签类,上面写有对应的营养成分,包括一些必有项:含量、卡路里等,以及一些可选项:总脂肪量、饱和脂肪量、胆固醇、钠等。

常规设计

1 重载构造器

最常想到的方法是通过重载构造方法,一个方法针对不同种类、数量的参数:

builder1

但这种做法在参数很多的情况下,灵活性几乎为0,设想有10个参数,那么可组合得到的构造方法就有\({2^{\rm{10}}}\)个。

2 setter方法

第二种方式类似于JavaBean,事先编写setter方法:

builder2

再针对需要配置的参数调用setter方法赋值:

builder3

这种方式非常灵活,可由程序员自由组合。但问题也随之而来(或者不如说是JavaBean本身的缺陷):对象的状态可能不一致!这是因为setter方法可以在对象生成以后的任意时刻,供给客户端调用,因此,如果该对象被其他多个java类(甲类、乙类)所共享,那么甲和乙均可任意修改该对象的属性(状态),如果该对象需要保持全局唯一(单例),或者再一般化点说,后期不可动态改变,那么setter带来的不安全性的这个缺陷就很明显了。

建造者模式

有没有什么设计方案既可以满足参数的灵活配置,又可以保证状态的不可变呢?答案是建造者模式。

如何实现呢?参数的灵活配置好说,只需要为每个参数编写类似于setter的方法供外部调用即可,但状态的不可变如何保证?不难看出,既然状态不可变,那就意味着对象的初始状态就决定了它以后的状态,而初始状态是由构造方法赋予的,因此我们只需要在构造的时候利用类似setter的形式配置好参数即可,而不再额外提供setter方法。

builder4
builder5

构建对象时这样使用:

builder6

可以看出建造者模式是在类的内部建立了一个内部类Builder,它含有与目标类一样的参数。先是利用Builder作为媒介将参数配置好,最后再调用build()一次性从Builder的this中提取参数,生成真正的我们需要的类对象的。另有两小细节:

  • 每配置完一个参数后返回的是Builder类,这样就能支持连续地配置参数了
  • 针对必需的参数,通常将其置于Builder()构造方法中,可配置参数再以setter形式提供

结语

建造者模式有利有弊,优点是:

  • 参数配置灵活
  • 保证对象状态一致,更安全
  • 中间对象Builder可以复用于之后任意多个目标对象的创建

缺点是代码比较冗长,创建目标对象之前必须先创建Builder,对于一些注重性能的场景(比如需要一次性创建海量的对象)来说不太合适。