问题标签 [factory-pattern]

Like the BeanFactory in java:

In the much more common case where the BeanFactory itself directly creates the bean by calling its constructor (equivalent to Java code calling new), the class attribute specifies the class of the bean to be constructed. In the less common case where the BeanFactory calls a static, so-called factory method on a class to create the bean, the class attribute specifies the actual class containing the static factory method.

Note:it's not the factory method

The $instance may be any class instance dynamically

目前我已经创建了一个 ABCFactory 类，它有一个创建 ABC 对象的方法。现在我想起来了，也许我可以在我的 ABC 方法中创建一个静态方法，而不是拥有一个工厂。进行此更改的利弊是什么？它不会导致同样的结果吗？我不预见其他类会继承 ABC，但永远不知道！

谢谢

我正在尝试使用工厂模式来创建 QuestionTypeFactory，其中实例化的类将类似于 MultipleChoice、TrueFalseQuestion 等。

工厂代码看起来像这样

现在这工作正常。如果我想添加另一个问题类型，我需要修改工厂类，我不想这样做。

如何设置它，以便每个问题类都向工厂注册，这样当我添加新的问题类型时，我不必更改工厂的代码？我对java有点陌生，不知道该怎么做。

编辑

附加信息

所有的问题类都实现了一个 IQuestion 接口。我正在寻找一种方法来实现类似的方法

这样我就可以从我的类的静态块中调用这个方法，这样当我添加一个新的问题类型时，我就不必在问题工厂中更改或添加任何代码。我知道我必须更改当前的实现以使其通用。我不确定我上面写的方法在语法上是否正确，但它显示了我想要的概念。

我正在浏览 SO 中的“工厂方法”页面，并遇到了这个链接。而这个评论。该示例看起来是一个变体，并被认为以其原始方式实现：将实例化推迟到子类......

这是我的尝试。以下代码是否实现了链接中指定示例的工厂模式？请验证并建议这是否必须进行任何重构。

我创建了一个工厂和一组规范来创建和验证聚合根。目前我对工厂进行了一些测试，调用工厂产品的规格，但我想知道这是否足够。从设计的角度来看，将工厂与其产品的规格结合起来可能会更好，因为它们是密切相关的。

如果聚合根产品的规范用于验证而不是创建，那么从工厂内部调用它是否有意义？

还是单元测试足够好？

这困扰了我一段时间，我不知道这是否是一个神话。

工厂模式似乎可以减轻为类添加依赖项的痛苦。

例如，在一本书中，它有这样的东西

假设您有一个名为 Order 的类。最初它不依赖于任何东西。因此，您不必费心使用工厂来创建 Order 对象，而只需使用 plain new 来实例化对象。但是，您现在需要创建与客户关联的订单。您需要更改数百万个位置才能添加此额外参数。如果您为 Order 类定义了一个工厂，那么您就可以满足新的要求而没有同样的痛苦。

这与向构造函数添加额外参数有何不同？我的意思是你仍然需要为工厂提供一个额外的参数，这也被数百万个地方使用，对吧？

我想知道我们什么时候需要使用抽象工厂模式。

这是一个例子，我想知道是否有必要。

UML

以上是抽象工厂模式，是我同学推荐的。以下是我自己的实现。我认为没有必要使用该模式。

以下是一些核心代码：

而 Test.properties 的内容只有一行：

所以任何ont可以告诉我这个西装是否有必要？

--------添加以下说明真正的适合--------------

我用道的例子是因为它很常见，任何人都知道。

其实我现在做的和DAO没有关系，我在做一个Web

服务，网络服务包含一些将文件更改为其他格式的算法，

例如：net.CreatePDF、net.CreateWord 等，它向客户端公开了两个接口：getAlgorithms 和 doProcess。

getAlogrithoms 将返回所有算法的 id，每个 id 都对应于相应的算法。

调用 doProcess 方法的用户也会提供他想要的算法 id。

所有算法都扩展了定义 run() 方法的 AbstractAlgorithm。

我使用 AlogrithmsRepository 来存储所有算法（来自

通过 web 配置算法的具体 java 类的属性文件

service admin)。也就是说web服务暴露的DoProcess接口是

由具体算法执行。

我可以举一个简单的例子：1）用户发送getAlgorithms请求：

然后用户将获得嵌入在 xml 中的算法列表。

2）用户通过以下方式向服务器发送 DoProcess：

当服务器收到此类请求时，它会根据“算法”参数（在此请求中为pdf）从AlgorithmRepostory中获取具体的算法实例。并调用方法：

然后一个pdf文件将被发送给用户。

顺便说一句，在这个例子中，每个算法都类似于 sqlDao,AccessDao。这是图像：

设计形象

现在，AlgorithmRepostory 是否需要使用抽象工厂？

这是我的问题，我正在考虑在 C++ 中使用工厂方法，你有什么意见？

有一个基类和许多子类。

我需要通过 TCP 在网络上传输对象。

我将在第一侧创建对象，并使用该对象创建一个字节数组 TCP 消息，并将其发送到另一侧。

另一方面，我将分解 TCP 消息，创建对象并将该对象添加到多态队列中。

在遗留代码库中，我有一个非常大的类，其中包含太多字段/职责。想象这是一个 Pizza 对象。

它具有高度精细的字段，例如：

• 有意大利辣香肠
• 有香肠
• 有甜椒

我知道，当这三个字段都成立时，我们就有了一个至尊披萨。但是，这个类不开放扩展或更改，所以我不能添加 PizzaType 或 isSupreme() 等。整个代码库中的人们到处重复相同的if(a && b && c) then isSupreme)逻辑。这个问题出现在很多概念上，所以我正在寻找一种方法来将此对象解构为许多子对象，例如伪向后的构建器模式。

这是正确的方法吗？这种模式是否已经存在？

我有一个名为 BitmapZone 的 Bitmap 类的包装类。

假设我们有一个 WIDTH x HEIGHT 位图图片，这个包装类应该用于允许我发送到其他方法/类本身而不是原始位图。然后我可以更好地控制用户可以或不允许对图片做什么（而且我不必多次复制位图来为每个方法/类发送）。

我的问题是：知道所有 BitmapZone 都是从位图创建的，你觉得什么更可取？

构造函数语法：类似于

工厂方法模式：

工厂方法模式：

其他？为什么？

谢谢