问题标签 [abstract-factory]

这是我对域模型和通用存储库的设计

当我想实例化一个存储库实例时，我使用一个实现以下接口的工厂

并使用工厂对象如下

我的问题在第二行。我想用我的工厂就好了。

由于我的 IRepository 接口对实体类型有约束，我的工厂使用相同的约束来满足 IRepository 要求。

有没有办法将此参数与客户端隔离？

我在 .Net 4.0 中使用 MEF 为我节省了大量的抽象工厂代码和配置 gubbins。无法移动到 .net 4.5，因为它未部署。

班上

调用之后_container.ComposeParts(this);，处理器会填充所有找到的 IMessageProcessor 实现。伟大的。

笔记

• GetMessageProcessor 被许多线程调用。
• 我们无法控制开发人员如何构建 IMessageProcessor 的类实现，因此我们不能保证它们是线程安全的 - 可重入。但是，该类必须使用 Export 属性进行检测。

导出属性

• ExpectedType 只是元数据，它记录了 IMessageProcessor.ProcessMessage() 期望处理的内容，纯粹是实现细节。

我的问题是，我到处都读到，每个 Imported 实例都是一个 Singleton，无论其通过 Lazy<> 引用构造时的激活策略如何。

因此，我们不能允许从 MEF 中的实例从 GetMessageProcessor 返回，因为多个线程将获取相同的实例，这是不希望的。啊！我想知道以下“解决方法”是否是最好的方法，或者我是否把 MEF 坚持概念弄错了。

我的解决方法是将看似毫无意义的RequiredCreationPolicy = CreationPolicy.NonShared属性设置更改为CreationPolicy.Shared.

然后更改函数 GetMessageProcessor 以手动创建一个新实例，与 MEF 完全分离。使用 MEF 共享实例 plurry 作为类型列表。

完整的方法；

我有汽车厂生产不同尺寸的汽车。我有 2 家工厂：美国和泰国，生产大、中、小汽车尺寸。但我有一个问题：泰国工厂不生产大型汽车。

代码：

我应该怎么办？我的抽象工厂设计得很糟糕吗？

我是 Unity 的新手，我很难弄清楚如何扩展 Unity 的汽车工厂概念。Unity 提供了开箱即用的能力，可以使用 Func 代替参数本身来创建工厂。像那样：

问题是，工厂创建的类在某些地方需要一些参数，而我只会在运行时知道这些参数。除此之外，这些参数的数量和类型因类而异。

我正在寻找类似于Autofac DelegateFactry的东西，但我想保持 Unity 的感觉。所以，我想让 Unity 像这样工作：

上面的代码不起作用，因为 Unity 确实可以使用该构造函数，但这正是我正在寻找的。

我尝试过使用 BuilderStrategy 但它归结为表达式或 IL 生成。在走这条路之前，我想检查一下其他选项。

有没有足够有Unity经验的人可以帮助我？

以下是我的限制：

1. 保持Unity使用Func的理念
2. 不需要在容器中注册每一个 Func
3. 构造函数应该接受从 Func 到 Func 的 Func（已经处理了 Func）
4. 更改容器不是一种选择

我希望我足够清楚。如果我不是，请告诉我。

编辑1：我知道我可以直接使用抽象工厂。但是，第一个目标是保持 Unity 的感觉。

一个理论问题。我正在阅读 Gof 的设计模式，抽象工厂部分。这本书提到了像原型一样实现这种模式的可能性，或者，如果语言允许的话，使用存储类而不是对象的原型。

我明白了这一点；例如在Java 或Smalltalk 中，类也是对象（在Java 中它们实际上是类Class 的实例）。因此，我们可以将它们存储在一个类中，并在需要时调用这些类的实例的创建。

在 C++ 中，类不是第一类对象。因此，我们不应该能够遵循这种方法。但是，我们不能在具体工厂中声明嵌套类，并使用调用它们的构造函数（并返回它们的实例）的方法吗？最终结果将与 Java 或 Smalltalk 等其他语言相同。我对吗？

感谢您的关注。

在抽象工厂模式中，我使用的是泛型。我有扩展 Serializable 的 BaseEntity 接口，Employee 类实现了 BaseEntity。在抽象类中，我有这个 getJavaObj 方法

getJavaObj()是一个接受 aLong empId并返回 a的方法Map<String, ? extends BaseEntity>

使用泛型我试图在它提供的主类中做到这一点；

它给出了这个错误类型安全：Unchecked cast from Map<String,capture#1-of ? extends BaseEntity>to Map

当我像这样进行类型转换时

它给出了这个警告

类型安全：未经检查的Map<String,capture#1-of ? extends Serializable>转换为 Map 类型安全：未经检查的Map<String,capture#1-of ? extends BaseEntity>转换为 Map

即使在类型转换之后，有没有办法避免类型转换或解决警告？由于我返回的对象确实通过 BaseEntity 接口扩展到 Serializable 。

我有一个 Java ThreadFactory 实现，在我的 Android 应用程序中产生可运行的线程子类对象。此应用程序要求所有衍生线程在某个事件触发之前都是可寻址的，并且在触发所述事件时，可以使衍生线程有资格进行垃圾收集（例如，引用计数为 0）。我在想，为了满足第一个要求，我只需维护我的线程对象的 ArrayList，并且效果很好。第二个要求带来了麻烦，这让我想到了一系列关于 Java 引用计数的问题：

问题 1：简单地将生成线程的引用存储在 ArrayList 或其他容器中会增加每个线程对象的引用计数吗？如果我从不存储它们，而是允许我的工厂创建它们并让它们在没有任何定义的句柄的情况下运行，那么每个线程对象的引用计数会是多少，如下所示？

问题 2：下面的代码示例是否对 hTempThread 指向的实际线程对象做任何事情，而不是增加并立即减少其引用计数？

问题 3：假设问题 2 的答案是“否”，那么存储由 ThreadFactory 实现产生的线程以便它们的引用计数可以按需减少到 0 的有效方法是什么？删除这些引用所涉及的正确语法是什么？下面的代码示例是否会有效地将所有涉及的对象（mvThreadsVector、tempThreads、mvThreadsVector 跟踪的每个线程对象）引用计数减少到 0？clear() 究竟对存储在 arraylist 中的对象的引用计数做了什么，将数组引用设置为 null 对存储在其中的元素的引用计数（如果有的话）有什么作用？

对于上述任何/所有问题的任何帮助将不胜感激！

我有一个简单的图表编辑器，在阅读了有关 IoC 和 DI 的书籍后，我决定尝试借助它们提供的帮助来解耦我的代码。看起来当用户将图表项目添加到图表时，项目由抽象工厂创建并添加到项目的内部图表列表中。但是当用户想要从图表中删除项目时该怎么办？首先我应该从内部列表中删除项目。然后我对sould i IoC.Release（Item）有一些误解吗？如果我不调用 IoC.Release(Item) （避免了解我的对象中的 IoC），那么 IoC 中的 Item 会发生什么。

PS：我正在尝试使用温莎城堡

我有以下健身俱乐部场景（用 C++ BTW 编码）：

我想创建随机的 Guest 和 Trainer 对象（因此两者都会随机生成名称，但来宾也会有随机的健康数据）。

我希望能够制作许多不同复杂度的随机生成器。

很明显，两者都需要随机名字/姓氏生成器功能 - 但我不确定如何将这段代码保存在一个地方。

我可以有一个包含所有生成方法（例如 generateForename()）的抽象工厂，所有需要随机生成的对象都可以使用它。但是，培训师是否应该有权访问可以生成健康数据的工厂，即使它与这些数据无关？

我还考虑过为每个类建立一个抽象工厂——一个用于人，一个用于客户，一个用于客人，并让对象通过将它们传递给适当的工厂来生成它们的超类，但这对于这种情况来说听起来过于复杂。

我对此很陌生，所以如果我的设计有点偏离，请原谅我。

你们有什么建议？

给定以下类层次结构

• A类需要B类
• B类需要C类

我们得到一个像这样的依赖图：

因此，如果我们使用 DI，我们将 ClassC 注入到 ClassB 中，将 ClassB 注入到 ClassA 中。

但是现在假设 ClassC 是一个运行时依赖项（例如某种策略）。注入运行时依赖项的建议方法是引入一个抽象工厂，如

现在我们可以将 ClassCFactory 注入 ClassB 并得到下图

现在我们在 ClassB 中有一个方法，我们可以调用它来让工厂完成它的工作。例如

但现在在我们的应用程序中，我们对 ClassB 一无所知（可能涉及更多层）。一种解决方案可能是在 ClassA 中有一个 SelectC

或者我们只是违反得墨忒耳法则并做类似的事情

我想每个人都同意第二种解决方案不是要走的路。但是第一个解决方案也有几个缺点，特别是如果我们之间有更多的层。

我们也可以将工厂上拉一级来创建 ClassB，但 ClassB 真的是运行时依赖吗？你建议什么解决方案？或者它甚至是一个糟糕的类设计？

恕我直言，最好依赖于对象实际需要什么来完成其工作，而不是依赖于创建所需对象的工厂。但是考虑到这个想法，DI容器将毫无用处......