为什么将类型与生成器结合在一起？

我最近在Code Review上删除了我的一个Java答案，它的开始是这样的：

private Person(PersonBuilder builder) {

停止。红色标志。一个PersonBuilder将建立一个Person；它知道一个人。Person类应该对PersonBuilder一无所知-这只是一个不可变的类型。您已经在此处创建了圆形耦合，其中A取决于B，而B取决于A。

该人员应仅获取其参数；愿意创建一个人而不创建它的客户应该能够做到这一点。

我被选票打了耳光，并告诉我（引用）红旗，为什么？这里的实现与Joshua Bloch在其“ Effective Java”书（项目2）中演示的形状相同。

因此，看来在Java 中实现构建器模式的一种正确方法是使构建器成为嵌套类型（尽管这不是这个问题），然后制造产品（正在构建的对象的类） ）对构建器的依赖，如下所示：

private StreetMap(Builder builder) {
    // Required parameters
    origin      = builder.origin;
    destination = builder.destination;

    // Optional parameters
    waterColor         = builder.waterColor;
    landColor          = builder.landColor;
    highTrafficColor   = builder.highTrafficColor;
    mediumTrafficColor = builder.mediumTrafficColor;
    lowTrafficColor    = builder.lowTrafficColor;
}

_{^{https://zh.wikipedia.org/wiki/Builder_pattern#Java_example}}

对于相同的Builder模式，相同的Wikipedia页面对于C＃具有非常不同的实现（并且更加灵活）：

//Represents a product created by the builder
public class Car
{
    public Car()
    {
    }

    public int Wheels { get; set; }

    public string Colour { get; set; }
}

如您所见，此处的产品对Builder类一无所知，并且它关心的所有事情都可以通过直接的构造函数调用，抽象工厂或构建器实例化。据我所知，产品创建模式的永远需要知道什么是创造任何东西。

我一直在接受反对论证（显然，在Bloch的书中明确辩护），可以使用构建器模式来返工一种类型，该类型会使构造函数with肿有许多可选参数。因此，与其坚持我的想法，不如我知道我在该站点上进行了一些研究，发现我怀疑，这种说法没有道理。

那怎么办？为什么要针对一开始就不应该存在的问题提出过度设计的解决方案？如果我们让约书亚·布洛赫（Joshua Bloch）离开他的基座一分钟，我们能否提出一个单一的，有效的理由来结合两种具体类型并将其称为最佳实践？

这一切对我来说都是崇尚货色的编程。

我不同意你的说法，这是一个危险信号。我也不同意您对对方的表示，即表示构建器模式的一种正确方法。

对我来说，有一个问题：生成器是否是类型API的必要部分？这里，PersonBuilder是Person API的必要部分吗？

完全有必要通过其提供的构建器来创建经过有效性检查，不可变和/或紧密封装的Person类（无论该构建器是嵌套的还是相邻的）。这样，“人员”可以保留其所有字段的私有性或“包私有性”以及“ final”，并且如果正在进行中的工作，还可以让该类开放供修改。（它可能最终因修改而关闭，而对于扩展却开放，但是现在这并不重要，对于不可变的数据对象尤其有争议。）

如果确实必须通过提供的PersonBuilder作为单个程序包级API设计的一部分来创建Person，则采用圆形耦合就可以了，此处不作任何保证。值得注意的是，您说这是一个无可争辩的事实，而不是API设计的观点或选择，因此可能导致不良响应。我不会拒绝您的投票，但我不会因此而怪罪他人，我将其余的“什么理由拒绝投票”的讨论留给了Code Review帮助中心和meta。投票失败；这不是“巴掌”。

当然，如果您想开放很多方法来构建Person对象，那么PersonBuilder可以成为使用者或实用程序不应该直接依赖的Person类。这个选择似乎更灵活-谁不想有更多的对象创建选项？-但是为了保持保证（例如不变性或可序列化性），Person突然不得不公开另一种公共创建技术，例如很长的构造函数。如果Builder是用来表示或替换具有很多可选字段的构造函数或开放修改的构造函数，则该类的long构造函数可能是一个实现细节，最好将其隐藏起来。（还请记住，一个正式且必要的Builder并不能阻止您编写自己的构造实用程序，只是您的构造实用程序可能像在我上面的原始问题中一样，将Builder用作API）。

ps：我注意到您列出的代码审查示例具有不变的Person，但是Wikipedia的反例列出了带有getter和setter的可变Car。如果您使语言和不变式保持一致，则可能更容易看到Car省略了必要的机械。

我理解在辩论中使用“呼吁权威”会带来多大的烦恼。争论应该站在他们自己的IMO上，尽管指出这样一个受人尊敬的人的建议是没有错的，但实际上它本身不能被认为是一个完整的争论，因为我们知道太阳绕着地球行进，因为亚里斯多德说过。

话虽如此，我认为你的论点前提是一样的。我们绝不应该将两种具体类型耦合在一起，并称其为最佳实践，因为……有人这样说？

为了使耦合有问题的论点成立，必须要解决一些特定的问题。如果这种方法不受这些问题的影响，那么您就无法从逻辑上论证这种耦合形式存在问题。因此，如果您想在这里提出自己的观点，我认为您需要说明此方法如何解决这些问题和/或取消构建器的耦合将如何改善设计。

副手，我正在努力查看耦合方法将如何产生问题。当然，这些类是完全耦合的，但是生成器仅用于创建类的实例。另一种看待它的方法是作为构造函数的扩展。

要回答为什么将类型与构建器结合使用，有必要了解为什么任何人首先都会使用构建器。特别是：当您具有大量构造函数参数时，Bloch建议使用构建器。这不是使用生成器的唯一原因，但我推测这是最常见的。简而言之，构建器是那些构造器参数的替代品，并且通常在与构建器相同的类中声明该构建器。因此，封闭的类已经了解了构建器，并且将其作为构造器参数传递并不会改变它。这就是为什么将类型与生成器结合在一起的原因。

为什么拥有大量参数意味着您应该使用构建器？嗯，拥有大量参数在现实世界中并不罕见，也不违反单一责任原则。当您有十个String参数并试图记住哪些是哪些以及是否应该为空的第五个或第六个String时，它也很糟糕。使用构建器可以更轻松地管理参数，还可以执行其他一些很酷的事情，您应该阅读本书以了解有关内容。

什么时候使用与它的类型不匹配的构建器？通常，当对象的组件无法立即使用并且具有这些组件的对象不需要了解您要构建的类型时，或者您为无法控制的类添加构建器时， 。

创建模式的产品永远不需要知道创建它的内容。

本Person类不知道什么是创造它。它只有一个带有参数的构造函数，那又如何呢？参数类型的名称以... Builder结尾，它实际上并没有强制执行任何操作。毕竟这只是一个名字。

构建器是一个出色的¹配置对象。 配置对象实际上只是将属于彼此的属性分组在一起。如果它们只是为了传递给类的构造函数而属于彼此，那就这样吧！二者origin与destination所述的StreetMap例子是类型的Point。是否可以将每个点的各个坐标传递到地图？当然可以，但是a的属性Point属于同一类，另外，您可以在其上使用各种有助于其构造的方法：

¹区别在于，构建器不仅是纯数据对象，而且允许这些链接的setter调用。将Builder主要关心如何构建自身。

现在让我们添加一些命令模式，因为如果仔细观察，构建器实际上就是一个命令：

1. 它封装了一个动作：调用另一个类的方法
2. 它包含执行该操作所需的信息：方法参数的值

对于构建者而言，特殊的部分是：

1. 该要调用的方法实际上是一个类的构造函数。现在最好将其称为创造模式。
2. 参数的值是构建器本身

传递给Person构造函数的内容可以构建它，但不一定必须如此。它可能是普通的旧配置对象或构建器。

不，他们完全错了，而您绝对正确。该构建器模型只是愚蠢的。构造函数参数的来源与Person无关。构建器只是为用户带来便利，仅此而已。