文章目录
- 1.前言
- 1.1.创建对象时的痛点
- 2.建造者模式
- 2.1 被建造类准备
- 2.2.建造者类实现
- 2.3.构建对象测试
- 2.4.使用lombok简化建造者
- 2.5.lombok简化建造者的缺陷
- 3.总结
1.前言
在我刚入行不久的时候就听说过建造者模式这种设计模式,当时只知道是用来组装对象,使用起来和先new
出对象再一个一个的set
字段值也差不多,没有去深究这种设计模式。后来随着在业务中写的代码越来越多,同时也去查阅了一些资料,慢慢的对这两者的区别有了一点理解。于是对为什么要用建造者模式,以及相对于直接set
的优劣势做一个简单的梳理。
1.1.创建对象时的痛点
在不同的业务流程需求当中,在创建了对象之后对于对象各个字段的赋值可能还会有一些额外的要求,这里举几个典型的例子:
- 对象中的某几个字段不能为空,或需要满足一定的校验要求。
- 字段与字段之间有联动,例如:填写了电话号码就不用填邮箱地址,但两者不能都为空
- 某些字段值只能创建时赋值一次,赋值后就不可变了
对于上面的这些需求,直接通过set
不是太好实现的,可以有这样一些思路:
- 在类的构造函数中写上校验、联动等逻辑
- 借助一下其他的方法,比如写一个静态工具方法,传入参数生成对象并返回
但是问题又来了,假如现在有好几个业务流程,每个流程当中需要set
不同的字段值,那就需要我们 针对每个不同的需求都创建对应的方法(或构造函数) 来生成不同的对象。
当这么做的时候,后续的迭代拓展会让方法越来越多,拓展变动越来越困难。
针对对象的字段组装需求上的痛点,可以使用建造者模式来处理,功能疑更易维护且更加内聚。
2.建造者模式
接下来就用建造者模式实现一下上面的需求,假设我们现在有一个Person
类型,包含了name,age,phone,email
字段,其中:
- name和age不能为空
- phone和email不能同时为空
- 所有的属性在创建时初始化,创建完成后不能再修改
2.1 被建造类准备
我们先创建一个Person
类,并且只提供get
方法,满足不能修改的需求,必要时还可以给每个字段加上final
修饰:
import lombok.Getter;@Getter
public class PersonModel {private String name;private Integer age;private String phone;private String email;
}
接下来就需要提供一个构造函数用于完成初始化工作,这个构造函数接收一个Builder
对象作为参数,这个对象就是我们接下来要说的建造者对象。
import lombok.Getter;@Getter
public class PersonModel {private String name;private Integer age;private String phone;private String email;// 用于初始化的构造函数public PersonModel(Builder builder) {this.name = builder.name;this.age = builder.age;this.phone = builder.phone;this.email = builder.email;}
}
2.2.建造者类实现
建造者类拥有与被建造的类相同的属性,同时给每个属性提供一个同名方法,这个方法用于给字段赋值,并且会返回建造者对象(方便链式调用),最后提供一个build
方法用于生成被建造的对象。
建造者类可以是一个独立的类,也可以是是被建造类的静态内部类,静态内部类的方式相对来说更加内聚,这里采用这种方式,完整的代码如下所示。
@Getter
public class PersonModel {private String name;private Integer age;private String phone;private String email;// 用于初始化的构造函数public PersonModel(Builder builder) {this.name = builder.name;this.age = builder.age;this.phone = builder.phone;this.email = builder.email;}// 建造者类public static class Builder {private String name;private Integer age;private String phone;private String email;public Builder name(String name) {this.name = name;return this;}public Builder age(Integer age) {this.age = age;return this;}public Builder phone(String phone) {this.phone = phone;return this;}public Builder email(String email) {this.email = email;return this;}public PersonModel build() {return new PersonModel(this);}}
}
我们之前提到的参数的验证就可以写在build
方法中:
public PersonModel build() {if (StringUtils.isBlank(name)) {throw new RuntimeException("姓名不能为空");}if (age == null) {throw new RuntimeException("年龄不能为空");}if (StringUtils.isBlank(phone) && StringUtils.isBlank(email)) {throw new RuntimeException("联系方式和邮箱不能同时为空");}return new PersonModel(this);
}
2.3.构建对象测试
完成之后就可以通过建造者类来组装和构建对象了,客户端在使用的时候可以灵活的选择要给哪些字段赋值,赋什么值,例如:
@Test
public void testBuildPerson() {PersonModel personModel = new PersonModel.Builder().name("挥之以墨").age(18).phone("123456789").build();
}
此时就会构建出一个personModel
对象,而当我们传入的参数不符合要求时就会根据我们build
中的写法,抛出异常给出相应的提示。
@Test
public void testBuildPerson() {PersonModel personModel = new PersonModel.Builder().name("挥之以墨").age(18).build();
}
2.4.使用lombok简化建造者
我们可以从上面看到,建造者类的编写还是比较繁琐的,如果没有build
函数中的各种操作需求,可以考虑直接使用lombok来生成建造者类,只需要加上一个@Builder
注解即可。
import lombok.Builder;
import lombok.Getter;@Getter
@Builder
public class PersonModelPure {private String name;private Integer age;private String phone;private String email;
}
编译后我们通过IDE打开.class
文件,可以看到反编译的代码如下,生成了一个建造者类:
需要注意的是,在使用lombok
来简化建造者之后,我们在源代码中由于没有建造者的源码,所以无法给Person
对象中的字段赋予默认值直接在Person
类的字段上赋值是无效的,会被构造方法覆盖。此时需要使用@Builder.Default
来标记有默认值的字段:
@Getter
@Builder
public class PersonModelPure {private String name;@Builder.Defaultprivate Integer age = 18;private String phone;private String email;
}
在反编译的代码中可以看到,如果没有给age
赋值,则会取默认值。
2.5.lombok简化建造者的缺陷
虽然我们可以使用lombok
来简化建造者,但我们现在抛开实现回来想一想使用建造者模式的目的是什么?
我们希望在创建对象的时候,有这么一个内聚的对象,能够自由的给对象组装不同的字段的能力,同时希望在字段与字段之间能够形成一点的联动、校验,满足一些特定的要求。
而使用lombok
来生成的建造者,能够满足这样的要求吗?
显然,它只是提供了一个自动生成建造者的能力,而没有关心生成这个建造者的目的是什么,所以它并不能满足我们使用建造者的需要。
如果说只是为了组装构建对象而编写一个建造者,相对于new
出对象之后,再一个一个set
字段值就没有什么优势了,后者编写起来还更加简单。
3.总结
本篇描述了如何实践建造者模式,同时也聊到了为什么要使用建造者模式。
简单的说,就是建造者模式提供了一种能力,让我们在自由的组装构建对象的同时,给到一定的约束。而这样的能力往往是用在框架代码中的,由架构提供建造者,开发者按照建造者的约束去相对自由的构建需要的对象。
在业务代码中,如果我们并没有太多这样的校验的要求,只是希望创建一个对象,直接new
并set
又何乐不为呢?
最后,如果觉得本文有所帮助的话,可以点赞收藏哦~
如果您有不同的见解,也可以留言一同讨论,共同学习进步!