用于抽象类的具体实现的构建器(Joshua Bloch 风格)? [英] Builder (Joshua Bloch-style) for concrete implementation of abstract class?

问题描述

假设我有一个抽象类 (BaseThing).它有一个必需参数(base required")和一个可选参数(base optional").我有一个扩展它的具体类 (Thing).它还具有一个必需参数(required")和一个可选参数(optional").所以就像:

Let's say I have an abstract class (BaseThing). It has one required parameter ("base required") and one optional parameter ("base optional"). I have a concrete class that extends it (Thing). It also has one required parameter ("required") and one optional parameter ("optional"). So something like:

public abstract class BaseThing {
    public static final String DEFAULT_BASE_OPTIONAL = "Default Base Optional";

    private final String baseRequired;
    private String baseOptional = DEFAULT_BASE_OPTIONAL;

    protected BaseThing(final String theBaseRequired) {
        this.baseRequired = theBaseRequired;
    }

    final void setBaseOptional(final String newVal) {
        this.baseOptional = newVal;
    }

    public final void selfDescribe() {
        System.out.println("Base Required: " + baseRequired);
        System.out.println("Base Optional: " + baseOptional);

        selfDescribeHook();
    }

    protected abstract void selfDescribeHook();
}

和:

public final class Thing extends BaseThing {
    public static final String DEFAULT_OPTIONAL = "Default Optional";

private final String required;
    private String optional = DEFAULT_OPTIONAL;

    Thing(final String theRequired, final String theBaseRequired) {
        super(theBaseRequired);
        required = theRequired;
    }

    @Override
    protected void selfDescribeHook() {
        System.out.println("Required: " + required);
        System.out.println("Optional: " + optional);
    }

    void setOptional(final String newVal) {
        optional = newVal;
    }
}

我想要一个 Joshua Bloch 风格的 Thing 对象构建器.更一般地说，我想让 BaseThing 的具体实现更容易拥有构建器，所以我真正想要的(我认为)是一个 BaseThing 构建器，它可以很容易地用于制作 ThingBuilder、OtherThingBuilder 或 SuperThingBuilder.

I want to have a Joshua Bloch-style builder for Thing objects. More generally, though, I want to make it easy for concrete implementations of BaseThing to have builders, so what I really want (I think) is a BaseThing builder that can easily be used to make a ThingBuilder, or an OtherThingBuilder, or a SuperThingBuilder.

有没有比我想出的以下更好的方法(或者我想出的方法有问题)?

Is there a better way than the following that I've come up with (or are there problems with what I've come up with)?

public abstract class BaseThingBuilder<T extends BaseThing> {
    private String baseOptional = BaseThing.DEFAULT_BASE_OPTIONAL;

    public BaseThingBuilder<T> setBaseOptional(final String value) {
        baseOptional = value;
        return this;
    }

    public T build() {
        T t = buildHook();
        t.setBaseOptional(baseOptional);

        return t;
    }

    protected abstract T buildHook();
}

和:

public final class ThingBuilder extends BaseThingBuilder<Thing> {
    private final String baseRequired;
    private final String required;
    private String optional = Thing.DEFAULT_OPTIONAL;

    public ThingBuilder(final String theRequired,
            final String theBaseRequired) {
        required = theRequired;
        baseRequired = theBaseRequired;
    }

    public ThingBuilder setOptional(final String value) {
        optional = value;
        return this;
    }

    protected Thing buildHook() {
        Thing thing = new Thing(required, baseRequired);
        thing.setOptional(optional);

        return thing;
    }
}

可用于以类似于以下方式构建 Thing 对象:

Which can be used to build Thing objects in a manner similarly to the following:

        BaseThingBuilder<Thing> builder = 
                new ThingBuilder("Required!", "Base Required!")
                    .setOptional("Optional!")
                    .setBaseOptional("Base Optional!");
        Thing thing = builder.build();
        thing.selfDescribe();

输出:

Base Required: Base Required!
Base Optional: Base Optional!
Required: Required!
Optional: Optional!

我知道但我认为不是特别重要的一个问题(尽管如果可以改进它会很好)是您必须在设置任何基数之前设置所有非基数选项选项:否则会导致语法错误，因为 setBaseOptional() 返回 BaseThingBuilder 而不是 ThingBuilder.

One issue that I know about, but that I don't consider particularly important (though if it can be improved it would be nice to do so) is that you have to set all non-base options before you set any base option: Doing otherwise would result in a syntax error, as setBaseOptional() returns a BaseThingBuilder rather than a ThingBuilder.

提前致谢.

推荐答案

我不认为这样考虑构建器是个好主意.构建器的层次结构通常会导致麻烦和脆弱的代码.

I don't think it's a good idea to think of builders that way. A hierarchy of builders usually leads to headaches and fragile code.

减少需要在具体构建器中编写的代码量并重用基础构建器中的逻辑与域密切相关.制定通用解决方案并不容易.但是，无论如何让我们尝试通过一个例子:

Cutting down the amount of code that needs to be written in the concrete builders and reusing logic from the base builder is closely tied to the domain. It's not easy to develop a general solution. But, let's try to go through an example anyway:

public interface Builder<T> {
  T build();
}

public class Person {
  private final String name;

  //the proper way to use a builder is to pass an instance of one to
  //the class that is created using it...
  Person(PersonBuilder builder) {
    this.name = builder.name;
  }

  public String getName(){ return name; }

  public static class PersonBuilder implements Builder<Person> {
    private String name;
    public PersonBuilder name(String name){ this.name = name; return this; }

    public Person build() {
      if(name == null) {
        throw new IllegalArgumentException("Name must be specified");
      }
      return new Person(this);
    }
  }
}

棒棒哒，宝贝！怎么办?也许您想添加一个类来代表学生.你做什么工作?你扩展人吗?当然，这是有效的.走一条更奇怪"的路线并尝试聚合怎么样?是的，您也可以这样做……您的选择会影响您最终实现构建器的方式.假设您坚持传统路径并扩展 Person(您应该已经开始问自己，Person 成为一个具体的类是否有意义?如果我将其抽象化，我真的需要一个构建器吗?? 如果类是抽象的，构建器应该是抽象的吗?):

Groovy, baby! Now what? Maybe you want to add a class to represent a student. What do you do? Do you extend Person? Sure, that's valid. How about taking a more "strange" route and attempting aggregation? Yep, you can do that too... Your choice would have an affect on how you will end up implementing builders. Let's say you stick to the traditional path and extend Person (you should already starting asking yourself, does it make sense for Person to be a concrete class? If I make it abstract, do I really need a builder? If the class is abstract should the builder be abstract?):

public class Student extends Person {
  private final long id;

  Student(StudentBulder builder) {
    super(builder);
    this.id = builder.id;
  }

  public long getId(){ return id; }

  //no need for generics, this will work:
  public static class StudentBuilder extends PersonBuilder {
    private long id;
    public StudentBuilder id(long id){ this.id = id; return this; }

    public Student build() {
      if(id <= 0) {
        throw new IllegalArgumentException("ID must be specified");
      }
      return new Student(this);
    }
  }
}

好的，这看起来正是你想要的！所以，你试试看:

Ok, this looks exactly like what you wanted! So, you try it:

Person p = new PersonBuilder().name("John Doe").build();
Student s = new StudentBuilder().name("Jane Doe").id(165).build();

看起来很棒！除了它不能编译...第 2 行有一个错误，它指出 The method id(int) is undefined for the type Person.PersonBuilder.问题是 PersonBuilder#name 返回类型为 PersonBuilder 的构建器，这不是您想要的.在StudentBuilder 中，您实际上希望name 的返回类型为StudentBuilder.现在，您提前考虑并意识到如果任何扩展 StudentBuilder 的内容，您都希望它完全返回其他内容...这可行吗?是的，使用泛型.然而，它非常丑陋，并引入了相当多的复杂性.因此，我拒绝发布说明它的代码，因为担心有人会看到这个线程并在他们的软件中实际使用它.

Looks great! Except, it doesn't compile... There's an error at line 2 and it states The method id(int) is undefined for the type Person.PersonBuilder. The problem is that PersonBuilder#name returns a builder of type PersonBuilder, which isn't what you want. In StudentBuilder you actually want the return type of name to be StudentBuilder. Now, you think ahead and realize that if anything extends StudentBuilder you'd want it to return something else entirely... Is that doable? Yes, with generics. However, it's ugly as hell and introduces quite a bit of complexity. Therefore, I refuse to post the code that illustrates it, for the fear that someone will see this thread and actually use it in their software.

您可能认为重新排列方法调用会起作用(在调用 name 之前调用 id):new StudentBuilder().id(165).name("JaneDoe").build()，但它不会.至少不是没有显式转换到 Student : (Student)new StudentBuilder().id(165).name("Jane Doe").build() 因为，在这种情况下，PersonBuilder#build 被调用，它的返回类型为 Person...这简直是不可接受的！即使它在没有显式转换的情况下工作，它也应该让您畏缩地知道必须按特定顺序调用构建器的方法.因为如果你不这样做，有些事情就行不通了...

You might think rearranging method calls will work (calling id before calling name): new StudentBuilder().id(165).name("Jane Doe").build(), but it won't. At least not without an explicit cast to Student: (Student)new StudentBuilder().id(165).name("Jane Doe").build() since, in this case, PersonBuilder#build is being called which has a return type of Person... This is simply unacceptable! Even if it worked without an explicit cast, it should make you wince to know that a builder's methods must be called in a certain order. Because if you don't, something won't work...

如果您继续尝试使其正常工作，还会出现更多问题.即使你确实让它工作了，我认为它不会很容易理解，当然也不优雅.当然，请随时证明我的错误并在此处发布您的解决方案.

There are many more problems that would arise if you continue trying to get it to work. And even if you did get it to work, I don't think it would be easily comprehensible and certainly not elegant. Of course, feel free to prove me wrong and post your solution here.

顺便说一句，您还应该问问自己什么是抽象构建器?因为，这听起来很矛盾.

By the way, you should also ask yourself what is an abstract builder? Because, it sounds like an oxymoron.

最后，我认为这个问题的范围太大了.答案是特定于领域的，如果没有您的要求，很难想出.请记住，建筑商的一般准则是让它们尽可能简单.

In the end, I believe that the scope of this question is too great. The answer is domain-specific and hard to come up with in the absence of your requirements. Just remember, the general guideline for builders is to have them be as simple as possible.

另外，看看一个相关问题.

这篇关于用于抽象类的具体实现的构建器(Joshua Bloch 风格)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！