工厂模式和我的无能。帮我看看光

Question

让我们保持简单......

class Client  
abstract class AbstractBusinessObject  
class BusinessObject  
class BusinessObjectFactory  

1. 好的，所以你的 Client 需要对 AbstractBusinessObject 执行一些操作。显然需要在某处创建一个BusinessObject 实例。为什么不在客户端？有什么害处？

2. 假设你说服我在我的BusinessObjectFactory 中创建新的BusinessObjects。伟大的。现在工厂不得不做繁重的工作。假设我的工厂有一个 Create(DataRow row) 方法，因为我的 BusinessObject 需要 DataRow 从中提取有用的信息。
   我的BusinessObject's 属性是{get; private set;}。因此我无法在我的工厂中分配任何属性值。反正我不应该。 然而，这意味着我必须完全传递DataRow。所以基本上工厂只是传递我的参数。这里的工厂有什么用？

3. 好的，所以我可能对BusinessObject 有不同的实现——它们每个都有不同的构造函数。我想工厂知道如何构建任何特定的BusinessObject 是有意义的。但话又说回来，我需要一个特定的工厂来获得一个特定的BusinessObject。至少我看到的所有例子都表明了这一点。 ConcreteFactoryB 创建 ConcreteProductB (ConcreteFactoryA 创建 ConcreteProductA) 客户如何知道如何建造工厂？或者甚至创建哪个？

4. 啊，工厂被注入了……组合根。对。但我也可以直接注入 BusinessObject。

5. DoFactory 上的示例让我觉得更清楚一点。是不是要确保Lion 不吃Bisons？而Wolf 不以Wildebeests 为食？如果这就是工厂试图确保我只想创建一个对象时不需要一个，对吧？

那么像this one here 这样的工厂有意义吗？如果我只有 one Create() 方法，它只生成一种类型的类，那么工厂是否有意义？

真的，我读了很多关于它的文章。 每个例子看起来都像另一个。我错过了重点:(谁能提供一个清晰的现实世界的例子？

https://stackoverflow.com/a/2280289/1407618
去过那里，做到了……

Answer 1

您是Person，使用AbstractComputer。你不关心电脑的品牌，只要它拥有AbstractComputer 拥有的所有基本东西。现在，为了使用计算机，您是自己Create() 还是从ComputerStore 或ComputerProvider 获得？这些将为您提供最适合您需求的计算机（即您的预算、技能、屏幕尺寸）。他们的AbstractComputer 是从知道如何最好地Create 他们的ComputerFactory 发货的。

至于AbstractComputer 的属性，有些可以交换Storage，有些则不能。这真的取决于你的上下文。但是为了让您的工厂将它们放入计算机中，如果它们在构造后不可交换，则它们需要一个入口点（构造函数）。

重要的一点是AbstractComputer 没有责任知道如何在给定碎片的情况下自己构建。 Consumer 也没有责任知道它需要哪种型号的计算机（如果他们有足够的知识并且他们的需求永远不会改变，他们有时可以）。

Answer 2

（看起来您接受依赖注入（通常）有用的想法，所以我将根据这个假设来回答。）

如果 A 的实例依赖于 B 的实例，并且您已经拥有 B 实例，那么您确实应该将其注入 A 实例而不使用工厂。但是，工厂在这些情况下很有用：

• 延迟加载：您在创建 A 时没有 B，因此 A 需要创建自己的 B（不知道 B 的确切类型，并且可能不知道 B 的（所有）依赖项）。
• 可选加载：在某些情况下，甚至可能不需要加载 B，是否必须由 A 决定。
• 多个实例：A 可能需要在任何时候创建 B 的多个实例。

像往常一样，没有模式是灵丹妙药，所以在很多情况下工厂或依赖注入都是矫枉过正的。您对工厂有用性的质疑很好，并且可能会导致您仅在该模式真正有用时才使用该模式。