问题标签 [builder-pattern]

构建器模式在创建不可变对象方面很流行，但是创建构建器需要一些编程开销。所以我想知道为什么不简单地使用配置对象。

构建器的用法如下所示：

很明显，这是非常易读和简洁的，但是你必须实现构建器：

我的想法是，通过使用这样的简单配置对象来减少代码：

用法：

这种用法需要多几行，但也非常易读，但实现要简单得多，对于不熟悉构建器模式的人来说可能更容易理解。顺便说一句：这种模式有名字吗？

我忽略的配置方法有缺点吗？

在使用工厂类和方法、模式等方面，我是一个完全的新手——事实上，我是在浏览 Java 相关问题时第一次在 Stackoverflow 上了解到它们的 :-)

在回答我之前的问题时，有人建议我研究在我的 GUI 开发中使用 Builder 模式，因此我正在寻找易于理解的示例，演示如何使用此模式将应用程序的用户界面放在一起，并且方法链等

谢谢阅读。

为什么我们不能在构造函数本身中进行不同的构建步骤。如果构建步骤带有参数，为什么不能将它们作为参数提供给构造函数并在构造函数中用于创建对象。

AFAIK，在 Builder 模式中，创建特定对象的客户端；那么在创建的类对象中使用构建器而不是带有参数的构造器有什么好处？

Builder 实现了 Cloneable 并覆盖了 clone() ，而不是复制构建器的每个字段，不可变类保留了构建器的私有克隆。这使得返回一个新的构建器和创建一个不可变实例的稍微修改的副本变得很容易。

这样我就可以走了

据说 Cloneable 接口有些损坏，但是这是否违反了良好的 java 编码习惯，这个结构有什么问题吗？

我现在在我的项目中有一个 Builder 模式的实例。目前，支持的输出格式是 CSV，但我现在想包含 YAML。容易，我想。我有所有支持代码来更改类型。

我发现自己有点复杂。使用 Builder 模式的目的是逐步构建输出文件。对我来说，这似乎与 YAML 直接矛盾 - 将所有对象放入一个数组并调用 YAML::dump()。

好消息是我确实有一组这些对象。它被传递给导演。这是 Director 的construct() 方法的一个片段。

我不确定如何同时适应 CSV 和 YAML 格式。有任何想法吗？

在我的一个项目中，我有两个包含 DTO、POJO 的包，只有 getter 和 setter。虽然它们是简单的 java bean 很重要（例如，因为 Apache CXF 使用它们来创建 Web 服务 XSD 等），但这样的编程也很糟糕并且容易出错。

我更喜欢流畅的接口和构建器对象，因此我使用 maven / gmaven 自动为 DTO 创建构建器。所以对于上面的代码，aFooBuilder是自动生成的，我可以这样使用：

我还为生成的构建器自动生成单元测试。单元测试将生成上述两个代码（构建器版本和非构建器版本）并断言两个版本在 和 方面是等效equals()的hashcode()。我可以实现的方法是拥有一个全局可访问的 Map，每个属性类型都有默认值。像这样的东西：

另一个重要的方面是 pojo 有时具有集合成员。例如：

但在我的构建器中，我希望从这种情况下生成两种方法：一个 set 方法和一个 add 方法：

我已经通过向属性字段添加自定义注释来解决这个问题Foo

builder builder (sic) 读取注解并使用该值作为要生成的方法的泛型类型。

我们现在越来越接近这个问题（对不起，简洁不是我的优点之一:-)）。

我已经意识到这种构建器方法可以用于多个项目，所以我正在考虑将它变成一个 maven 插件。我非常清楚如何生成一个 Maven 插件，所以这不是问题的一部分（也不是如何生成有效的 Java 源代码）。我的问题是：如何在不引入任何常见依赖项（项目和插件之间）的情况下处理上述两个问题：

<Question>

1. 我需要一个 Defaults 类（或类似机制）来获取生成的单元测试的默认值（这是概念的关键部分，如果没有完全测试，我不会信任自动生成的构建器）。请帮我想出一个好的通用方法来解决这个问题，因为每个项目都有自己的域对象。

2. 我需要一种将泛型类型与构建器生成器通信的通用方式。我正在使用的当前基于注释的版本并不令人满意，因为项目和插件都需要了解相同的注释。

</Question>

有任何想法吗？

顺便说一句：我知道使用构建器的真正关键点是使对象不可变。我不能让我的不可变，因为标准的 java bean 是必需的，但是我使用 AspectJ 来强制在我的代码库中的任何地方都没有调用 set-methods 和构造函数，除了在构建器中，因此出于实际目的，生成的对象是不可变的.

另外：是的，我知道现有的 Builder-generator IDE 插件。这不符合我的目的，我想要一个自动化的解决方案，只要底层代码发生变化，它总是最新的。

Matt B 请求了一些关于我如何生成我的构建器的信息。这就是我所做的：

我每次反射读取一个类，用于Introspector.getBeanInfo(clazz).getPropertyDescriptors()获取属性描述符数组。我所有的构建器都有一个基类AbstractBuilder<T>，在上述情况下T。Foo这是Abstract Builder 类的代码。对于PropertyDescriptor数组中的每个属性，都会生成一个带有属性名称的方法。这将是FooBuilder.bar(String)：

中的build()方法AbstractBuilder实例化对象并分配其属性映射中的所有属性。

最近，我在尝试编写有关请求的参数数量的类时被撕裂了。

一个非常简单的构造函数示例：

VS

这两种方式都是有效的方法。第一种方法准确地显示了汉堡的内容，将参数分解为更通用的类，从而减少耦合，我认为通常更容易测试，因为对象图更简单。

但是第二种方式更简单、更干净，也许汉堡需要更多的配料，那么第一种方式的争论就会大大增加。

我想知道在这种情况下会推荐哪种方式？选择更简洁但更耦合的代码，或者更冗长的方式。

我最近一直在与一个研究小组一起研究设计模式，并且已经了解到构建器模式对于创建由许多（可能是可选的）部分组成的复杂对象非常有用。

但是，是否存在建造商做得太多的地方？假设我们有一个包含许多不同对象组合的类，是否有另一种模式可能更适合于此，而不是制作数十个不同的构建器？是否可以通过不制作完全特定的构建器来减少所需的构建器数量？

我和我的学习小组经常提到的例子是汽车制造商，例如在汽车公司的网站上。任何一家汽车公司都有数十辆汽车，每辆都有许多不同的功能、颜色、附加功能等。按照我的理解，您的构建器应该特定于您正在制作的确切对象，因此将构建器模式应用于此示例将产生数百个看起来像“RedSUVWithSunroofBuilder”、“BlueSUVWithSunroofBuilder”、“RedSUVBuilder”等的建造者。

是否有任何理由使用构建器模式，我无法传递其中一些值来减少我需要创建的构建器的数量？例如，不是使用 RedSUVWithSunroofBuilder 或 BlueSUVWithSunroofBuilder，而是使用 SUVWithSunroofBuilder("Red") 和 SUVWithSunroofBuilder("Blue") 是否仍然适合构建器模式，还是更适合不同的模式？

我最近开始阅读 Joshua Bloch 的 Effective Java。我发现 Builder 模式的想法 [书中的第 2 项] 非常有趣。我试图在我的项目中实现它，但出现编译错误。以下本质上是我试图做的事情：

具有多个属性的类及其构建器类：

我尝试使用上述类的类：

我收到以下编译器错误：

需要包含有效java.BuilderPattern.NutritionalFacts.Builder 的封闭实例 NutritionalFacts n = new NutritionalFacts.Builder(10).carbo(23).fat(1).build();

我不明白消息的含义。请解释。上面的代码类似于 Bloch 在他的书中提出的例子。

这不是一个困难的问题。我只是想知道您认为这两个 C++ 代码片段中哪一个更好（可读性 vs. 长度vs.boiler-platery）：

选项1

选项#2

我个人更喜欢第一个选项，但这可能是因为我是代码的作者并且已经知道代码的作用（对于不知道代码的人来说可能会感到困惑）。我更喜欢它，因为它显示了对Entity对象而不是Entity::Builder对象的关注（并且因为它更短）。