问题标签 [builder-pattern]

我想澄清我对构建器模式的使用，特别是构建器类型是如何创建的。在示例中，它只是假设构建器的类型并创建它。但是，我CreateBuilder在“ChartBuilderFactory”类中创建了一个方法，该方法根据传递给它的某个对象返回构建器的类型。这是最好的方法吗？我已经发布了我的示例代码，并希望获得更好的设计的替代方案和建议。

我使用 Joshua Bloch 的 Builder 模式编写了一个类，类似于这个 Pizza 示例：

但 PMD 报告了 2 个警告：

1. （指向方法 Builder.build()）避免通过构造函数类外部的私有构造函数进行实例化。通过构造函数类外部的私有构造函数进行实例化通常会导致生成访问器。工厂方法或构造函数的非私有化可以消除这种情况。生成的类文件实际上是一个接口。它使访问类能够调用一个新的隐藏包范围构造函数，该构造函数将接口作为补充参数。这将私有构造函数有效地转换为具有包范围的构造函数，并且难以辨别。
2. 类不能被实例化并且不提供任何静态方法或字段。不能使用具有私有构造函数且没有任何静态方法或字段的类。

我应该忽略这些警告吗？

Pizza另一个问题：类中的私有字段Builder是重复的。当私有字段的数量变大时，这会很烦人。有什么办法可以避免吗？

我正在使用构建器模式为控制器生成视图模型，当我尝试对控制器进行单元测试时，我发现自己无法这样做。起订量抱怨。

不确定这是起订量限制还是我自己的限制和无知。

这是我的控制器的样子：

我正在尝试模拟IOutletViewModelBuilder对象，但这就是我得到的：

（1）给我以下错误突出显示（mockBuilder.Object）

无法解析方法“Returns(ViewModelBuilders.Builders.IOutletViewModelBuilder)”，候选者是：

(2)抛出以下错误：

无法解析方法“Returns(Moq.Mock)”，候选者是：

(3)不抛出编译时错误，而是抛出运行时错误：

任何帮助将不胜感激。对这种方法进行单元测试应该不难，不是吗？

如果您需要查看实现，您可以在下面看到 Builder 对象。

最后是IOutletViewModelBuilder接口

编辑：我不担心以错误的顺序调用，因为这是通过使用多个接口强制执行的，我只是担心终端方法被调用。

我正在使用构建器模式在我们的系统中创建权限。我选择了构建器模式，因为安全性在我们的产品中非常重要（它涉及未成年人，所以COPPA等），我觉得权限可读性非常重要，并且认为可读性是最重要的（即使用流利的风格builder 模式，而不是具有 6 个值的单个函数）。

代码如下所示：

这些方法填充了一个私有后备bean，当终端方法（即 asOf ）提交对数据库的权限时；如果没有调用该方法，则不会发生任何事情。开发人员偶尔会忘记调用终端方法，这不会导致编译器错误，并且在快速阅读/浏览代码时很容易错过。

我能做些什么来防止这个问题？我不想返回需要保存的 Permission 对象，因为这会引入更多噪音并使权限代码更难阅读、遵循、跟踪和理解。

我曾考虑在终端命令标记的支持上放置一个标志。然后，检查finalize方法中的标志，如果对象是在没有持久化的情况下创建的，则写入日志。（我知道finalize不能保证运行，但这是我能想到的最好的。）

我正在考虑在 C++ 单元测试中使用构建器模式，以简化为正在测试的代码创建输入数据。

在 Java 中，常见的习惯用法似乎是让构建器类的设置器返回（对）构建器对象本身的（引用），以便可以将多个设置器链接在一行中。例如。builder 类可以这样定义：

然后像这样使用：

通过让设置器返回对构建器对象的引用，可以在 C++ 中实现相同的效果。但是，我无法在网上找到任何这样的例子。这种“链接”是 C++ 中的常见做法吗？如果没有，那为什么不呢？

我是设计模式的新手。
我想创建一个类的实例，比如 ClassA，并将它的一些字段设置为从配置文件中读取的值。
如果我将类的代码与使用值管理文件的代码区分开来，那么 ClassA 就变成了一个纯粹的“业务逻辑”类。

我会说这是一种构建器模式，因为构建器似乎“不仅负责实例化”，还负责初始化。
但除此之外，builder 似乎专注于逐步打破创建过程，而在我的情况下，我只有一个（但复合的）步骤。

可以被认为是构建器模式吗？还是有什么不同？

在我们的上一个项目中，我们最终为我们的单元测试提供了一个共享的测试夹具，这带来了很多问题。因此，在我们当前的项目中，我研究了构建器模式。我们在开发机器的内存中运行我们的单元测试，并针对构建服务器上的数据库运行我们的单元测试。

目前我有一个 T4 模板，例如为学生生成以下构建器：

通过基类，我可以通过以下方式使用它：

我们在构建服务器上运行集成测试，以确保一切都对数据库有效。这意味着我们必须确保满足所有引用约束。但随后问题就开始了。

例如，要求学生有导师，导师属于学校，学校对城市，城市对......

这将导致如下代码：

我应该如何优化这个？我曾考虑在每个 Builder 的 Construct 方法中做“默认建筑”，但如果我要建造 10 个学生，那么它将导致 10 个城市 10 个学校的 10 个导师......

或者可能创建像 WithAllCity(..)、WithAll(School) 这样的方法

有任何想法吗？我真的以正确的方式使用构建器模式吗？导演班能帮上忙吗？或者我应该从 StudentBuilder 继承类来解决这些不同的情况？

或者另一个想法，在将数据发送到数据库之前，我应该在我的服务层中添加更多验证吗？然后我会在针对内存数据库的单元测试中发现更多错误。

我必须BenchmarkOption根据命令行参数创建一个类的实例。我当然使用 pojo 风格，但这不是一成不变的。所以我使用Java风格的Builder Pattern。这是我实现的类：

如您所见，代码冗长且不擅长阅读。我认为有一种替代方法可以重写它。有什么建议吗？

我目前正在使用此处定义的构建器模式：

上一个问题显示了我对构建器模式的使用

我现在遇到的问题是需要创建以下结构：

或者：

两者ZipHolder和File都是使用构建器模式构造的，实现为每个的内部静态类。AZipHolder将 amainFile作为强制的构造函数参数，并在 中预填充一些信息ZipHolder，如果需要，可以覆盖这些信息。AFile包含文件内容和与该文件有关的相关元数据。ZipHolder然后File在调用build()每个Builder类的方法时对两者进行验证。然后获取对象并将其输出到 ZIP 文件层次结构，如果需要，该层次结构随后应读入相同的对象结构。

这很好地工作，并在确保不变性的同时为对象创建提供了一定程度的灵活性。虽然我遇到了一个问题。提出了一个新要求，要求File对象可以具有元数据和文件内容，也可以只有文件 内容。我想我可以简单地将一个布尔标志值传递给对象的构建器，以允许跳过通常的元数据验证。这看起来没问题，但它需要构建一个mainFile - 本质上是一个先有鸡还是先有蛋的情况。我的下一个想法是将旗帜移到课堂上。这似乎没问题，直到我意识到您可能会创建多个ZipHolderFile FileFile对象，有些需要元数据，有些只需要文件内容，无法全面实施约束。

所以我对如何进行有些困惑。我看不到以优雅的方式将mainFile的需求解耦的明显方法。ZipHolder我想到了抽象类、接口、基类之类的概念，但在这种特殊情况下我需要一些指导。

所以我的问题是：

根据上面链接中的原因，我可以在保留构建器模式的同时允许这两种情况吗？

我有一个Class A包含相当多的成员变量。为了使其不可变并在构造过程中验证成员变量，我将其构造函数设为私有并使用内部公共静态构建器类 ( ClassABuilder) 来构建它。（Joshua Bloch 有效的 Java，第 2 项）。

现在我不明白的是，其他程序员将如何子类Class A化以实现他们自己的特定行为。我从书中阅读了 Builder Pattern 的缺点，但没有看到子类化被提及。我错过了什么吗？有没有一种优雅的方式来解决这个问题？

制作构造函数protected是我的想法之一，但它仍然会采用 public static ClassABuilder，那么如何在子类中添加新的成员变量？