问题标签 [creation-pattern]

我们有一个发布抽象基类的库：

（说明性伪代码）

/include/reader_api.hpp

在库实现中，有一个ReaderApi读取 pcap 文件的具体实现：

/lib/pcap_reader_api.cpp

客户端代码应PcapReaderApi通过工厂方法实例化这些对象之一：

这在几个层面上让我感觉很恶心。

首先，工厂方法应该是免费的，而static不是ReaderApi. 它是明确命名空间的static成员。ReaderApi无论哪种方式，我都可以看到利弊。随意对此发表评论，但这不是我的主要争论点。

其次，我的直觉告诉我我应该使用std::make_unique而不是调用工厂方法。但由于创建的实际对象是一个实现细节，而不是公共标头的一部分，因此客户端无需make_unique.

就可理解性和代码维护而言，最简单的解决方案似乎是我上面已经提出的解决方案，除非有更好的解决方案我还不知道。性能在这里不是主要考虑因素，因为由于此对象的性质，它只会在启动时实例化一次。

考虑到代码的清晰性、可理解性和可维护性，有没有比我这里更好的方法来设计这些对象的创建？

我已经考虑了两个替代方案，我将在下面讨论。

我考虑过的一种替代方法是将某种标识符传递给通用Create函数。标识符将指定客户希望构建的对象类型。它可能是一个enum class，沿着这些方向：

但我不确定我是否看到了这样做的意义，而不是仅仅让 create 函数变得自由和明确：

我还考虑过在的构造函数中指定DeviceType参数：ReaderApi

这将启用make_unique成语：

但这显然会带来一个大问题——你实际上是在尝试构建 a ReaderApi，而不是 a PcapReader。解决这个问题的明显方法是实现一个virtual constructor成语或使用工厂构造。但是对于我来说，虚拟构造似乎过度设计用于此用途。

它们之间有什么区别，而不是通过键设置和获取数组中的对象？

我有一个 Item 对象，它有 4 个字符串字段和 3 个布尔字段。我必须基于 3 个布尔变量来构造这个对象。目标是每当布尔变量中的任何一个为真时，我们都必须创建具有该/那些布尔变量集的对象。如果在任何情况下都没有布尔变量为真，我们将不会创建对象。我正在使用 COR 来检查是否会根据某些业务逻辑设置任何布尔字段。我正在使用构建器尝试此操作，但随后我必须构造这么多对象，然后在没有布尔变量发现为真时丢弃它们。

谁能有更好的主意来解决这种问题？

好吧，感谢这个问题的 2 删除标志。也感谢您对这个问题的想法。我做了一些事情来实现我想要的。我相信这是非常灵活的。只有部分依赖于 If 循环，但这是可以接受的，因为 Report 类可以具有额外的布尔值，因此当该类发生更改时，应该触摸它的构建器以适应该更改。休息这是我想要的灵活。公共类报告{

calculateInconsitencyReport() 方法将决定是否创建对象。

助手接口：

由于安全性，类逻辑的细节被撕掉了。

客户端通过基类（java代码）使用它们：

createNewConcreteFeature只会从地图中获取 requiredFeature 值并返回一个实例。这似乎是一种在派生类中是静态的方法，但是客户端无法使用现有对象创建派生类实例。有没有更优雅的写法？或者这有一些适用的模式吗？

前提：我正在尝试放弃构造函数模式

正如你在console.log()这里看到的

Object.createAPI创建的对象具有__proto__引用原型的属性，Object而构造函数创建的对象具有引用原型的属性作为__proto__构造函数的名称。

我想这种行为是试图模拟强类型语言，假设您的构造函数定义了一个由构造函数名称本身标识的新类型。

也就是说，当我的原型链增长时，我发现通过名称/“类型”识别不同的原型非常有用，那么有什么方法可以正确地使用它Object.create而不是构造函数？

考虑以下接口（使用哑指针，因为我们还在 C++98 中）

通过以下可能的实现

Widget 是一些带有虚拟析构函数的基类，SpecificWidget 扩展了它。我的同事声称 WidgetMaker 界面应包含以下方法

基本原理是这样我们不强制 makeWidget 实现使用标准的新分配，他们可以使用自定义池分配器或总是返回相同的全局实例，以防小部件是无状态的或其他。

我觉得这样的设计通常是一个坏主意——它使客户端代码复杂化，违反了 KISS 和 YAGNI，使得（在我们的组织中不太可能在未来 20 年内）过渡到 unique_ptr 更加困难。我应该相信我的感觉吗？什么情况下自由方法作为抽象工厂接口的一部分是合理的？

我已经构建了一个通用（抽象）构建器，它将为将在测试期间使用的实体构建器提供基本实现。

这是实体基类：

这是IKey 接口：

这是Builder 类：

这是一个示例UnitBuilder实现：

这就是我遇到的问题：

错误：

错误 CS1061“Builder”不包含“WithShort”的定义，并且找不到接受“Builder”类型的第一个参数的扩展方法“WithShort”（您是否缺少 using 指令或程序集引用？）

我了解发生了什么，但我想要一个比thirdUnit.

更新：

根据建议，我在UnitBuilder课堂上添加了以下内容：

但是现在我在基类中看不到任何意义......这必须是一个通用的通用基类问题，其他人如何处理这个问题？也许thirdUnit解决方案很优雅，但我只是对此感到困难？:)

我有这个问题是因为：

我知道当您必须创建复杂对象（它们的构造函数很大）时应该使用构建器模式（据我所知），而工厂是为了拥有一个负责实例化对象的类，这样您就可以实现低耦合和高内聚

但是，由于 builder 和 factory 是创建模式，我不知道同时使用它们是否有意义或正确。

提前致谢。

我的程序有两个课程；两者都派生自同一个基类。

InitVal是另一个通过构造函数注入的类。此类供内部使用。由于内部构造函数，用户无法直接创建类的A实例B。相反，我创建了创建这些对象的方法。

ObjectInstance是上面代码中的枚举。

这可以毫无问题地工作，但我相信您之前从未见过如此丑陋的代码。

请建议我应该使用的创作模式。我想删除ObjectInstance枚举而不改变功能。它会清理很多。

我尝试了dotfactory上提到的创建模式。 在这种情况下看起来不合适。Factory MethodAbstract Factory

我的代码虽然看起来很丑，但阅读和理解起来非常简单。我尝试实现上述增加代码复杂性的模式。所以这也是我选择答案的标准。

Initiator除了类，我无法更改代码中的任何内容。我无法访问所有其他类进行编辑。

编辑1：为什么上面的代码在我看来很难看

1) 在调用CreateObject方法时，用户必须两次指定对象的类型。

首先是T通用值，其次是枚举值。我想避免这种情况。

2) 由于用户必须两次指定对象类型，因此有出错的机会。

在上面的代码中，枚举值和通用值是不同的。这是不允许的，这将是一个问题。使用我的代码，我无法避免这种情况。

这就是为什么; 我正在寻找适合我的情况而又不增加复杂性的模式。

如果我以某种方式消除枚举的必要性，代码会好得多。如果我可以将签名更改CreateObject为以下，那会好得多。

但是，我不确定我将如何实现此方法来创建适当的实例。

在一个项目中，当月的风格似乎是使用 switch 语句和枚举来决定要创建什么具体的类实例。

考虑到它们都实现相同的接口，但在创建实例时需要不同的对象参数，是否可以考虑用于对象创建的替代设计模式？

例如，当前代码是。