问题标签 [builder-pattern]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
design-patterns - 建造者设计模式和工厂设计模式有什么区别?
建造者设计模式和工厂设计模式有什么区别?
哪一个更有优势,为什么?
如果我想测试和比较/对比这些模式,如何将我的发现表示为图表?
c# - 后代可见的公共类成员
作为另一个类的公共类成员,我从构建器模式中获得了很大的吸引力:
注意受保护的构造函数 - 我喜欢我必须使用生成器来获取零件的方式。来电
工作得很好。我想做的是使用这个构建器来提供基于类型的特殊部件(例如):
并对构建器进行了轻微更改:
但这不起作用 - Part.Builder 看不到 SpecialPart 的受保护构造函数。如何让 Builder 使用 Part 的后代并获得相同的 must-have-a-builder 语义?
design-patterns - 建造者模式会取代工厂模式吗?
我知道这个问题被问了很多次,但我只是想澄清更多。建造者模式可以代替工厂模式吗?
是的,Builder 模式逐步创建并返回一个复杂的对象,这也可以在工厂模式中完成。
design-patterns - 如何在 C# 中为具有引用类型属性的对象创建构建器?
我已经开始构建一个构建器,以便我可以轻松地为我正在编写的单元测试创建测试数据。
构建器的基本结构是:
那么这个模式的用法就变成了:
我对此很满意......但我有疑问的是什么时候MyClass
有一个非平凡的属性......我有点不确定如何用默认值构造它。
我的假设是我会创建一个构建器MySecondClass
并使用它来创建默认实现。
谁能确认我的假设是正确的并且是最佳实践?
我目前正在测试我的假设,但我想我会在 StackOverflow 上记录这个想法,因为我可以使用 google 找到的构建器模式的唯一示例只构建了值类型而不是引用类型的属性。
java - 如何改进建造者模式?
动机
最近我在寻找一种方法来初始化一个复杂的对象,而不需要向构造函数传递很多参数。我尝试使用构建器模式,但我不喜欢这样一个事实,即我无法在编译时检查是否真的设置了所有需要的值。
传统建造者模式
当我使用构建器模式创建Complex
对象时,创建过程更加“类型安全”,因为更容易看到参数的用途:
但是现在我有一个问题,我很容易错过一个重要的参数。我可以在方法中检查它build()
,但这只是在运行时。在编译时,如果我遗漏了什么,没有任何东西可以警告我。
增强的构建器模式
现在我的想法是创建一个构建器,如果我错过了所需的参数,它会“提醒”我。我的第一次尝试是这样的:
如您所见,构建器类的每个设置器都返回一个不同的内部构建器类。每个内部构建器类只提供一个 setter 方法,最后一个只提供一个 build() 方法。
现在对象的构造再次看起来像这样:
...但是没有办法忘记所需的参数。编译器不会接受它。
可选参数
如果我有可选参数,我会使用最后一个内部构建器类Builder4
来设置它们,就像“传统”构建器一样,返回自身。
问题
- 这是众所周知的模式吗?它有一个特殊的名字吗?
- 你看到任何陷阱吗?
- 您是否有任何改进实施的想法 - 在更少的代码行的意义上?
design-patterns - 建造者模式和享元模式有什么区别?
构建器模式和享元模式在使用方面有什么区别,因为它们都处理大量对象?
language-agnostic - 你会在哪里使用构建器模式而不是抽象工厂?
我已经多次看到这个问题出现在这里和那里,但我从未找到并回答我满意的答案。
来自维基百科:
Builder专注于一步一步地构建一个复杂的对象。抽象工厂强调一系列产品对象(简单或复杂)。Builder 作为最后一步返回产品,但就抽象工厂而言,产品会立即返回。
但是对于客户来说不是一样的吗?一旦构建完成,他就会获得完整的对象,因此对他来说没有额外的功能。
我认为它的唯一方法是作为一种方式或逐步组织构造函数代码,以强制构建构建器实现的结构。这很好,但与抽象工厂相差甚远。
来自 Wikipedia 的下一点是一个很好的参考,可以说明我的观点:
通常,设计从使用工厂方法(不太复杂、更可定制、子类激增)开始,然后随着设计人员发现需要更多灵活性的地方而向抽象工厂、原型或构建器(更灵活、更复杂)发展。
如果是这样,那么在您的系统中必须引入什么样的复杂性,您将从抽象工厂更改为构建器?
我的观点是,我找不到一个很明显抽象工厂不够用的例子,而你需要一个 Builder。
design-patterns - 测试数据生成器是否应该为其非原始构造默认值?
我创建了一个数据构建器,以便在我的单元测试中创建测试数据。我的数据构建器为所有属性创建默认值,以便使用它们的测试只需要指定适用于测试的属性。
考虑以下构建器:
通过这样做,如果我需要在 id 对我很重要但 Order 无关紧要的测试中创建客户,我可以按如下方式创建对象:
这是一个好主意吗?或者有什么理由认为应该如何构造非原始属性可能不是最好的?
c# - 自动生成不可变类和匹配的构建器类
存在哪些工具/库将采用结构并自动生成不可变的包装器以及用于增量构建新实例的“构建器”类?
示例输入:
示例输出:
这样的“工具”可以是 IDE 插件,也可以在运行时使用反射生成新类。
该示例使用 C#,但我会对任何静态类型的 OO 语言(Java、Scala、C++ 等)的解决方案感兴趣。
理想的功能:
- 从构建器类中的结构重新创建方法
- 从不可变类中的结构重新创建非破坏性方法(尤其是
Equals()
和GetHashCode()
任何接口方法) - 还为每个结构成员生成一个
IFooReader
包含只读属性的接口,由不可变和构建器实现。 - 如果字段的类具有不可变等效项,则在不可变类中使用不可变版本(另请参阅如何在 C# 中为具有引用类型属性的对象创建构建器?)例如
List
->ReadOnlyCollection
或类似的。 - 或者将构建器类作为输入(构建器使用自动属性而不是委托给结构。)
- 不需要
Clone
预定义方法
“你不应该使用这样的工具,因为......”也欢迎回答。
java - 伪向后生成器模式?
在遗留代码库中,我有一个非常大的类,其中包含太多字段/职责。想象这是一个 Pizza 对象。
它具有高度精细的字段,例如:
- 有意大利辣香肠
- 有香肠
- 有甜椒
我知道,当这三个字段都成立时,我们就有了一个至尊披萨。但是,这个类不开放扩展或更改,所以我不能添加 PizzaType 或 isSupreme() 等。整个代码库中的人们到处重复相同的if(a && b && c) then isSupreme)
逻辑。这个问题出现在很多概念上,所以我正在寻找一种方法来将此对象解构为许多子对象,例如伪向后的构建器模式。
这是正确的方法吗?这种模式是否已经存在?