我将不深入讨论该模式,因为已经有大量的帖子和书籍对此进行了详细的解释。 相反,我将告诉您为什么以及何时应该考虑使用它。 但是,值得一提的是,这种模式与《 四人帮》一书中介绍的模式有些不同。 虽然原始模式着重于抽象化构造步骤,以便通过更改所使用的构建器实现可以得到不同的结果,但本文中说明的模式用于消除不必要的复杂性,该复杂性是由多个构造函数,多个可选参数以及过度使用二传手。
假设您有一个包含大量属性的类,例如下面的User类。 假设您要使该类不可变(顺便说一句,
除非有充分的理由不这样做,否则您应该始终努力。 但是我们将在另一篇文章中讨论)。
public class User {private final String firstName; //requiredprivate final String lastName; //requiredprivate final int age; //optionalprivate final String phone; //optionalprivate final String address; //optional
...
}
现在,想象一下您的类中的某些属性是必需的,而其他属性是可选的。 您将如何构建此类的对象? 所有属性都声明为final,因此您必须在构造函数中全部设置它们,但您也想让此类的客户端有机会忽略可选属性。
第一个有效的选择是拥有一个仅将必需属性作为参数的构造函数,一个将所有必需属性加上第一个可选属性作为参数的构造函数,而另一个将两个可选属性作为参数的构造函数,依此类推。 看起来像什么? 像这样:
public User(String firstName, String lastName) {this(firstName, lastName, 0);}public User(String firstName, String lastName, int age) {this(firstName, lastName, age, '');}public User(String firstName, String lastName, int age, String phone) {this(firstName, lastName, age, phone, '');}public User(String firstName, String lastName, int age, String phone, String address) {this.firstName = firstName;this.lastName = lastName;this.age = age;this.phone = phone;this.address = address;}
用这种方法构造类的对象的好处是它可以工作。 但是,这种方法的问题应该很明显。 当您只有几个属性时,没什么大不了的,但是随着数量的增加,代码变得更难以阅读和维护。 更重要的是,对于客户而言,代码变得越来越难。 我应该作为客户端调用哪个构造函数? 一个带有2个参数? 一个3? 不传递显式值的那些参数的默认值是多少? 如果我想为地址设置一个值而不是年龄和电话该怎么办? 在那种情况下,我将不得不调用接受所有参数的构造函数,并为那些我不在乎的参数传递默认值。 此外,具有相同类型的几个参数可能会造成混淆。 第一个String是电话号码还是地址?
那么对于这些情况我们还有什么选择呢? 我们总是可以遵循JavaBeans约定,在该约定中,我们有一个默认的no-arg构造函数,并且每个属性都有设置器和获取器。 就像是:
public class User {private String firstName; // requiredprivate String lastName; // requiredprivate int age; // optionalprivate String phone; // optionalprivate String address; //optionalpublic String getFirstName() {return firstName;}public void setFirstName(String firstName) {this.firstName = firstName;}public String getLastName() {return lastName;}public void setLastName(String lastName) {this.lastName = lastName;}public int getAge() {return age;}public void setAge(int age) {this.age = age;}public String getPhone() {return phone;}public void setPhone(String phone) {this.phone = phone;}public String getAddress() {return address;}public void setAddress(String address) {this.address = address;}
}
这种方法似乎更易于阅读和维护。 作为客户端,我可以只创建一个空对象,然后仅设置我感兴趣的属性。那么这有什么问题呢? 该解决方案有两个主要问题。 第一个问题与使此类的实例处于不一致状态有关。 如果要创建一个具有其所有5个属性值的User对象,则在调用所有setX方法之前,该对象将不具有完整状态。 这意味着客户端应用程序的某些部分可能会看到此对象,并假定该对象已经构造,而实际上并非如此。 这种方法的第二个缺点是现在User类是可变的。 您失去了不可变对象的所有好处。
幸运的是,对于这些情况,还有第三种选择,即构建器模式。 解决方案将如下所示。
public class User {private final String firstName; // requiredprivate final String lastName; // requiredprivate final int age; // optionalprivate final String phone; // optionalprivate final String address; // optionalprivate User(UserBuilder builder) {this.firstName = builder.firstName;this.lastName = builder.lastName;this.age = builder.age;this.phone = builder.phone;this.address = builder.address;}public String getFirstName() {return firstName;}public String getLastName() {return lastName;}public int getAge() {return age;}public String getPhone() {return phone;}public String getAddress() {return address;}public static class UserBuilder {private final String firstName;private final String lastName;private int age;private String phone;private String address;public UserBuilder(String firstName, String lastName) {this.firstName = firstName;this.lastName = lastName;}public UserBuilder age(int age) {this.age = age;return this;}public UserBuilder phone(String phone) {this.phone = phone;return this;}public UserBuilder address(String address) {this.address = address;return this;}public User build() {return new User(this);}}
}
需要注意的几个要点:
- User构造函数是私有的,这意味着不能从客户端代码直接实例化此类。
- 该类再次是不可变的。 所有属性都是最终属性,它们是在构造函数上设置的。 此外,我们仅为他们提供吸气剂。
- 构建器使用Fluent Interface惯用法使客户机代码更具可读性(我们稍后将看到一个示例)。
- 构建器构造函数仅接收必需的属性,并且此属性是在构建器上唯一定义为“最终”的属性,以确保在构造函数上设置其值。
生成器模式的使用具有我一开始提到的前两种方法的所有优点,并且没有任何缺点。 客户端代码更易于编写,更重要的是易于阅读。 我听到的关于该模式的唯一批评是,您必须在构建器上复制类的属性。 但是,考虑到构建器类通常是它构建的类的静态成员类,因此它们可以很容易地一起进化。
现在,尝试创建新的User对象的客户端代码如何? 让我们来看看:
public User getUser() {return newUser.UserBuilder('Jhon', 'Doe').age(30).phone('1234567').address('Fake address 1234').build();}
很整洁,不是吗? 您可以用1行代码构建一个User对象,最重要的是,它很容易阅读。 而且,您要确保每当获得此类的对象时,都不会处于不完整状态。
这种模式非常灵活。 通过在对“ build”方法的调用之间更改构建器属性,可以使用单个构建器来创建多个对象。 构建器甚至可以自动完成每次调用之间生成的某些字段,例如ID或序列号。
重要的一点是,就像构造器一样,构造器可以对其参数施加不变性。 构建方法可以检查这些不变量,如果它们无效则抛出IllegalStateException 。
将参数从构建器复制到对象之后,必须检查它们,并在对象字段而不是构建器字段上检查它们,这一点至关重要。 这样做的原因是,由于生成器不是线程安全的,因此,如果我们在实际创建对象之前检查参数,则可以在检查参数与复制参数之间的另一个线程更改它们的值。 该时间段称为“漏洞窗口”。 在我们的用户示例中,这可能类似于以下内容:
public User build() {User user = new user(this);if (user.getAge() 120) {throw new IllegalStateException(“Age out of range”); // thread-safe}return user;
}
以前的版本是线程安全的,因为我们首先创建用户,然后检查不可变对象上的不变量。 以下代码在功能上看起来相同,但是它不是线程安全的,因此应避免执行以下操作:
public User build() {if (age 120) {throw new IllegalStateException(“Age out of range”); // bad, not thread-safe}// This is the window of opportunity for a second thread to modify the value of agereturn new User(this);
}
这种模式的最后一个优点是可以将构建器传递给某个方法,以使该方法能够为客户端创建一个或多个对象,而该方法无需了解有关如何创建对象的任何种类的细节。 为此,通常需要一个简单的界面,例如:
public interface Builder {T build();
}
在前面的User示例中, UserBuilder类可以实现Builder <User> 。 然后,我们可能会有类似的内容:
UserCollection buildUserCollection(Builder<? extends User> userBuilder){...}
好吧,那是一篇相当长的第一篇文章。 综上所述,对于具有多个参数的类(不是一门精确的科学,但我通常将4个属性用作使用该模式的一个很好的指标),Builder模式是一个绝佳的选择,尤其是当这些参数中的大多数是可选的。 您将获得易于阅读,编写和维护的客户端代码。 此外,您的类可以保持不变,这使您的代码更安全。
更新 :如果将Eclipse用作IDE,事实证明您有很多插件可以避免该模式随附的大多数样板代码。 我见过的三个是:
- http://code.google.com/p/bpep/
- http://code.google.com/a/eclipselabs.org/p/bob-the-builder/
- http://code.google.com/p/fluent-builders-generator-eclipse-plugin/
我没有亲自尝试过其中任何一个,因此我无法真正做出明智的决定。 我认为其他IDE应该也存在类似的插件。
参考:开发 人员实践中来自JCG合作伙伴 Jose Luis 的构建者模式, 它应该是博客。
翻译自: https://www.javacodegeeks.com/2013/01/the-builder-pattern-in-practice.html