问题标签 [factory]

我有一堆 MDI 子节点，它们都是以相同的方式创建的，为了减少冗余代码，我希望能够调用一个方法，向它传递一个字符串（子节点的名称），让它创建节点并将其添加到父级。

除了从类名的字符串创建类之外，我可以做所有的事情，我该怎么做？

在我正在处理的项目中，我们有一个聚合域对象。工厂对象处理对象唯一 ID 的创建。但是有一个单独的导入过程，它最初创建没有 id 的相同对象。要将导入的对象添加到系统中，我们现在被迫逐个字段地复制到一个新对象，因为出于显而易见的原因，我们不能只为其设置 id。任何人都可以提出更好的方法来处理这种情况吗？

我最近在 python 中发现了元类。

基本上，python中的元类是一个创建类的类。您想要这样做的原因有很多——例如任何类型的类初始化。在工厂上注册类、复杂的属性验证、改变继承的工作方式等等。所有这些不仅变得可能而且变得简单。

但在 python 中，元类也是普通类。所以，我开始想知道抽象是否可以有用地更高，在我看来它可以而且：

• 元类对应或实现模式中的角色（如在 GOF 模式语言中）。
• 元元类就是模式本身（如果我们允许它创建代表抽象角色的类元组，而不仅仅是一个类）
• meta-meta-metaclass 是一个模式工厂，它对应于 GOF 模式分组，例如 Creational、Structural、Behavioural。一个工厂，您可以在其中描述某种类型的问题的案例，它会为您提供一组解决它的类。
• 一个 meta-meta-meta-metaclass （据我所知），是一个模式工厂 factory，一个你可以描述问题类型的工厂，它会给你一个模式工厂来询问。

我在网上找到了一些关于这个的东西，但大多不是很有用。一个问题是不同的语言对元类的定义略有不同。

有没有其他人在 python/其他地方使用过这样的元类，或者在野外看到过这个，或者考虑过它？其他语言的类似物是什么？例如，在 C++ 中，模板递归能走多远？

我非常想进一步研究它。

我想要一种干净的方式来创建游戏对象，例如 NPC、子弹和道具，从而减少对特定类的相互依赖量。我相信这就是工厂模式的用途？

我很想从真正的游戏中看到一个好的实现。

我不是设计模式方面的专家，如果我不理解它们，就永远不要使用它们。我不想为了它而使用设计模式——我只想了解这种模式是否是解决这个问题的正确方法。

我正在使用温莎城堡作为我的 IoC 容器，但遇到了一些问题。这在代码中得到了最好的解释，所以我会试一试。我有一个工厂类，它应该为我提供某个接口的实现：

工厂类的实现可能如下所示，但我不确定这是要走的路： public interface ObjectCreatorFactory:IObjectCreatorFactory { IEnumerable specificCreators; IObjectCreator 默认创建者；

现在这样就可以了，但是如果我希望我的 IObjectCreator 实例使用特定的 IObjectCreator 创建子对象，我想调用 ObjectCreatorFactory，这显然会导致循环引用：

这行不通。在这种情况下，创建的对象将引用回工厂以供子对象创建者使用，该怎么做？

您使用工厂而不是构造函数来创建对象的阈值是多少？

1. 你总是使用工厂。
2. 仅当您有除检查空值之外的不变检查时，您才使用工厂。
3. 你总是使用构造函数
4. 你很少使用工厂......那些情况是什么？

利弊

更新：我在我的项目中应用域驱动设计的工厂模式。创建工厂的原因之一是减少领域模型中的噪音。

谢谢

我有一堂课

如何在此类中声明和定义返回 StaticVector<3> 对象的静态工厂方法，例如

?

我正在使用 Scala 隐式为 Java 接口定义一个丰富的包装器：

在伴生对象中，我定义了隐式转换和apply工厂方法：

有了这个，我可以实例化接口的 Java 实现并像使用它一样RichThing（由于隐式转换）：

我还可以RichThing使用工厂方法创建一个（由于apply方法）：

我想做的是以相同的方式实例化接口的任意 Java 实现。这不起作用，因为 Scala 然后寻找实现的伴随对象但​​找不到：

我可以为 Java 实现创建一个 Scala 伴随对象：

但关键是要使该接​​口适用于任何（特别是未知的）实现。

有没有办法实现这一点？例如，基于对象中的隐式转换为 Java 实现动态创建 Scala 伴生RichThing对象？

或者从 Java 端创建 Scala 伴生对象，也许在抽象类中？

最近我一直在考虑保护我的一些代码。我很好奇如何确保永远不能直接创建对象，而只能通过工厂类的某种方法。假设我有一些“业务对象”类，我想确保此类的任何实例都具有有效的内部状态。为了实现这一点，我需要在创建对象之前执行一些检查，可能在其构造函数中。在我决定让这个检查成为业务逻辑的一部分之前，这一切都很好。那么，我怎样才能安排一个业务对象只能通过我的业务逻辑类中的某些方法而不是直接创建呢？使用 C++ 的好老“朋友”关键字的第一个自然愿望将在 C# 中失败。所以我们需要其他选择...

让我们尝试一些例子：

没关系，直到您记得您仍然可以直接创建 MyBusinessObjectClass 实例，而无需检查输入。我想完全排除这种技术可能性。

那么，社区对此有何看法？

我有一个带有几个派生类的 ABC。要创建这些派生类，我使用工厂模式：

.h 文件：

.cpp 文件：

与仅具有免费功能相比，这有什么好处：

.h 文件：

.cpp 文件：

另外：我使用抽象工厂模式进行依赖注入。我可能会使用基于 ABC 的继承层次结构：

在函数指针上使用它有什么好处：

使用 boost::bind/lambda 这似乎使我的代码更具可组合性，如果我希望我可以在其中包装一个真正的工厂对象。我可以看到性能可能会略有下降，但这很值得担心，因为它只在启动期间调用。