我从未真正研究过工厂模式，今天决定花时间根据本文创建一个快速示例（http://msdn.microsoft.com/en-us/library/ee817667.aspx http://msdn.microsoft.com/en-us/library/ee817667.aspx），终于让我明白了。
源代码完美地排列在三个独立的程序集中，整齐地命名为“产品”、“工厂”和“客户端”。
工厂模式的主要好处（据我所知）是从“Client”类中抽象出“product”类的实例化。因此，在提供的示例中，无论对产品类进行任何更改，产品实例化都不会更改，您仍然必须对客户端类进行更改以传递创建更新产品所需的新值。这些数据到底一定来自某个地方？
我读到的另一个例子指出，一旦实现了一个类并且其他类的负载直接使用它，对此处的“产品”类进行的更改将需要对该类的每个实例进行更改，例如，如果其构造函数中需要新变量。
据我所知，工厂模式确实确保此类的实例化永远不会改变，如果您想将新变量传递给产品构造函数，您最终只需将这些新变量传递给更新后的工厂即可。
因此，这显然并没有解决问题，而只是移动它，这样做会增加额外的复杂性。
鉴于这是一个既定的模式，我显然错过了一些东西。因此这篇文章：请向我解释我缺少什么。
Thanks
当您可以拥有同一接口的许多不同实现时，可以使用工厂，并且仅在运行时决定客户端实际需要哪一个。然而，客户端不需要知道它实际使用的是哪个实现。这就是工厂介入的地方：它封装了创建具体对象的细节，并将其作为所需接口的通用实现返回。
事实上，有两种不同的模式与 Factory 名称相关：抽象工厂 http://en.wikipedia.org/wiki/Abstract_factory_pattern and 工厂方法 http://en.wikipedia.org/wiki/Factory_method_pattern。后者用于创建单个产品的实例，而前者可用于创建整个相关产品系列。
抽象工厂的一个典型示例是在 GUI 框架中创建一系列小部件。框架的客户端可能只需要知道他们正在处理一个窗口、状态栏或按钮；然而，它们不必与实际小部件是 Windows 还是 MacOS 小部件这一事实联系在一起。这允许创建可以在这些平台中的任何一个上运行的客户端；理论上，当框架移植到新平台（例如 Linux）时，所需要做的就是实现一个新工厂来生成所有 Linux 特定的小部件，并通过配置将其插入。你瞧，客户端在 Linux 上运行，没有注意到任何差异，甚至可能不需要重新编译客户端代码（至少在理论上，在某些语言中 - 我知道关于多平台 GUI 的现实是不同的，但这只是一个例子 ：-）
将此与尝试在没有工厂的情况下实现相同的方法进行比较：您将在客户端代码中的许多地方需要决定需要创建哪个特定于平台的小部件。每当您想要引入新的小部件系列时，您都需要修改代码中的每个位置，以向许多相同的小部件添加新分支switch or if/else块。此外，由于您将公开处理特定于平台的小部件对象，因此某些特定于平台的小部件特性和实现细节可能会泄漏到客户端代码中，从而使移植到其他平台变得更加困难。
无论对产品类进行任何更改，产品实例化都不会更改，您仍然需要对客户端类进行更改以传递创建更新产品所需的新值。这些数据到底一定来自某个地方？
的确。如果总体实例化过程发生变化，Factory接口也可能需要相应改变。这不是Factory的重点。尽管您可以在构建时将数据传递给工厂，然后每当创建新产品时工厂都可以在后台使用这些数据。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
