Java 生成器应该计算参数值吗

假设我有以下类和一个生成器：

public class A(){
    private B b;
    private C c;

    private A(Builder builder) {
       this.b = builder.b;
       this.c = bulder.c;
    }

    public static class Builder() {
       private B b;
       private C c;

       public Builder setB(B b){
           this.b = b;
           return this;
       }

       public Builder setC(C c){
           this.C = c;
           return this;
       }

       public A build(){
          return new A(this);
       }
    }
}

现在让我们假设b和c需要以某种方式进行计算（例如，基于D的列表）。可能的问题是：

---

根据某些计算，填充参数b和c应该放在哪里，也就是说，我应该将计算放在A、builder还是其他地方

如果

A

知道，我会根据是否可以更改列表

D

来选择选项。如果可以，则需要能够重新计算属性，因此应该自己进行计算。如果

D

是给

a

的固定列表，那么属性可以“缓存”并预先计算

这对我来说似乎是构建器的一个奇怪用法。你为什么选择一个建筑商？如果

b

和

c

不是可选的，那么

A

应该通过构造函数要求它们。生成器应该用于设置

A

的可选（或可配置）属性，我不会将生成器传递给

A

。这不是完整的类，只是一个示例。有更多的参数是可选的，因此生成器是可选的。我在某处发现了一个类似这样的实现，比如一个例子，构造函数A是私有的，所以这样我就避免了一个大型构造函数，它的主体与本例中的相同，只是参数将直接传递，而不是生成器。如果我通过构造函数传递参数b和c，我会打破生成器的概念吗？我将把其他可选参数放在哪里？如果

b

和

c

不是可选的，那么构建器不会提供任何优势，事实上它会产生一个问题，如果我不调用

setB

？如果它们是可选的，则只需创建一个

A

（在生成器的构造函数中），并在调用生成器方法时将它们设置为

A

。有关强制生成器方法的讨论，请参阅此问题：