到目前为止,我使用的是构建器模式的following实现(与描述的here实现相反):
public class Widget {
public static class Builder {
public Builder(String name, double price) { ... }
public Widget build() { ... }
public Builder manufacturer(String value) { ... }
public Builder serialNumber(String value) { ... }
public Builder model(String value) { ... }
}
private Widget(Builder builder) { ... }
}这对于我遇到的大多数情况都很有效,我需要用各种必需的/强制的和可选的参数来构建一个复杂的对象。然而,我最近一直在努力理解当你的所有参数都是强制的(或者至少是绝大多数参数)时,该模式是如何带来任何好处的。
解决这个问题的一种方法是对传递给它们自己的类的参数进行逻辑分组,以减少传递给构建器构造函数的参数数量。
例如,而不是:
Widget example = new Widget.Builder(req1, req2, req3,req4,req5,req6,req7,req8)
.addOptional(opt9)
.build();按如下方式分组:
Object1 group1 = new Object1(req1, req2, req3, req4);
Object2 group2 = new Object2(req5, req6);
Widget example2 = new Widget.Builder(group1, group2, req7, req8)
.addOptional(opt9)
.build();虽然单独的对象简化了很多事情,但如果一个人不熟悉代码,也会让事情变得有点难以理解。我考虑的一件事是将所有参数移动到它们自己的addParam(param)方法中,然后对build()方法中所需的参数执行验证。
什么是最佳实践,有没有我没有考虑过的更好的方法?
发布于 2011-09-05 08:31:52
构建器/工厂仍然允许您将接口与实现类型解耦(或者允许您插入适配器等),假设Widget成为一个接口,并且您有办法注入或隐藏new Widget.Builder。
如果您不关心解耦,并且您的实现是一次性的,那么您是对的:构建器模式并不比普通的构造器更有用(它仍然用每个构建器方法的属性样式标记其参数)。
如果您反复创建参数变化很小的对象,那么它可能仍然很有帮助。您可以传入、缓存等在插入几个属性后获得的中间构建器:
Widget.Builder base = new Widget.Builder(name, price).model("foo").manufacturer("baz");
// ...
Widget w1 = base.serialNumber("bar").build();
Widget w2 = base.serialNumber("baz").build();
Widget w3 = base.serialNumber("quux").build();这假设您的构建器是不可变的:构建器设置器不设置属性并返回this,而是返回自身的一个新副本。正如您在上面指出的,参数对象是绕过重复参数样板的另一种方法。在这里,您甚至不需要构建器模式:只需将参数对象传递给您的实现构造函数。
https://stackoverflow.com/questions/7302891
复制相似问题