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

最新推荐文章于 2022-12-04 23:12:47 发布

dnc8371

最新推荐文章于 2022-12-04 23:12:47 发布

阅读量146

点赞数

文章标签： java python 设计模式 android linux

原文链接：https://www.javacodegeeks.com/2013/01/the-builder-pattern-in-practice.html

版权

工厂模式构建者模式

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

假设您有一个包含大量属性的类，例如下面的User类。假设您要使该类不可变（顺便说一句，

除非有充分的理由不这样做，否则您应该始终努力。但是我们将在另一篇文章中讨论）。

public class User {
    private final String firstName;    //required
    private final String lastName;    //required
    private final int age;    //optional
    private final String phone;    //optional
    private 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; // required
	private String lastName; // required
	private int age; // optional
	private String phone; // optional
	private String address;  //optional

	public 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; // required
	private final String lastName; // required
	private final int age; // optional
	private final String phone; // optional
	private final String address; // optional

	private 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 new
				User.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 age
    return new User(this);
}

这种模式的最后一个优点是可以将构建器传递给某个方法，以使该方法能够为客户端创建一个或多个对象，而该方法无需知道有关如何创建对象的任何种类的细节。为此，通常需要一个简单的界面，例如：

public interface Builder {
    T build();
}

在前面的User示例中， UserBuilder类可以实现Builder <User> 。然后，我们可能会有类似的内容：

UserCollection buildUserCollection(Builder<? extends User> userBuilder){...}

好吧，那是一篇相当长的第一篇文章。综上所述，对于具有多个参数的类（不是一门确切的科学方法，但我通常将4个属性用作使用该模式的一个很好的指标），Builder模式是一个很好的选择，尤其是当这些参数中的大多数是可选的。您将获得易于阅读，编写和维护的客户端代码。此外，您的类可以保持不变，这使您的代码更安全。

更新：如果将Eclipse用作IDE，事实证明您有很多插件可以避免该模式随附的大多数样板代码。我见过的三个是：

我没有亲自尝试过其中任何一个，因此我无法真正做出明智的决定。我认为其他IDE应该也存在类似的插件。

参考：开发 人员实践中来自JCG合作伙伴 Jose Luis 的构建者模式，它应该是博客。