工厂模式构建者模式_实践中的构建者模式

工厂模式构建者模式

我将不深入讨论该模式，因为已经有大量的文章和书籍对此进行了详细的解释。相反，我将告诉您为什么以及何时应该考虑使用它。但是，值得一提的是，这种模式与《四人帮》一书中介绍的模式有些不同。虽然原始模式着重于抽象化构造步骤，以便通过更改所使用的构建器实现可以得到不同的结果，但本文中说明的模式用于消除不必要的复杂性，该复杂性是由多个构造函数，多个可选参数以及过度使用二传手。

假设您有一个包含大量属性的类，例如下面的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，事实证明您有很多插件可以避免该模式随附的大多数样板代码。我见过的三个是：