为什么工厂模式的工作方式呢？ [英] Why does factory pattern work the way it does?
问题描述
源代码完美排列在三个独立的组件中，整齐地命名为产品，工厂和客户端。
主要的好处（据我所知）为Factory模式从Client类抽象出产品类的实例化。因此，在提供的示例中，产品实例化从不改变，无论对产品类做出任何更改，您仍然必须对客户端类进行更改，以传递创建更新产品所需的新值。这个数据毕竟来自某个地方？
另一个我读的例子说明，一旦实现了一个类，并且其他类的负载直接使用它，这里的产品类将需要对此类的每个实例化进行更改，例如，如果在其构造函数中需要一个新变量。
从什么我可以理解，工厂模式确实确保这个类的实例化不会改变，如果你想将一个新的变量传递给产品构造函数，那么你最终必须将这些新变量传递给更新的工厂。
因此显然不能解决问题，只是移动它，这样做会增加额外的复杂性。
一个既定的模式，我显然是缺少一些东西。因此这篇文章：请向我解释我所缺少的东西。
谢谢
当您可以有相同接口的许多不同实现时，使用工厂，并且只决定运行时客户端实际需要哪一个。然而，客户端不需要知道它实际使用哪个实现。这是工厂步骤：它封装了创建具体对象的细节，并将其作为所需界面的一般实现返回。
实际上有两个不同与名称相关联的模式工厂：抽象工厂和工厂方法。后者用于创建单个产品的实例，而前者可用于创建一整套相关产品。
抽象工厂的典型示例是创建的GUI框架中的一系列小部件。框架的客户可能只需要知道他们在处理窗口，状态栏或按钮;然而，它们不需要束缚实际的小部件实际上是Windows或MacOS小部件的事实。这样可以创建可以在这些平台上运行的客户机;理论上，当框架移植到一个新的平台（比如说Linux）的时候，所需要的就是实现一个生产所有Linux特定小部件的新工厂，并通过配置将其插入。 Lo，客户端运行在Linux上，并没有注意到任何差异，可能甚至不需要重新编译客户端代码（至少在理论上，在某些语言中，我知道多平台GUI的现实是不同的，但这只是一个例子： - ）
比较这个来试图实现相同的没有工厂：你会有很多地方在客户端代码中，你需要决定哪个平台特定的小部件你需要创建。每当你想介绍一个新的小部件系列时，您需要修改代码中的每个这些位置，以便在许多相同的开关或 if / else 块。此外，由于您将公开处理特定于平台的部件对象，所以有可能某些特定于平台的小部件特性和实现细节将泄漏到客户端代码中，从而使其更难以端到其他平台。
产品实例化永远不会改变，无论对产品类做出任何更改，您仍然需要更改客户端类以传递新的必需值创建更新的产品。这些数据毕竟来自某个地方？
的确。如果一般的实例化过程发生变化，Factory接口也可能需要更改。这不是工厂的重点。虽然您可以在施工时将数据传送到工厂，但是当创建新产品时，可以在后台使用数据。
I've never really looked at the Factory pattern and today decided to take the time and create a quick sample based on this article (http://msdn.microsoft.com/en-us/library/ee817667.aspx), to finally get my head around it.
The source code works perfectly arranged in three separate assemblies neatly named Product, Factory and Client.
The main benifit (as I understand it) for the Factory pattern is to abstract the instantiation of the "product" class from the "Client" class. So in the provided example, the Product instantiation never changes irrespective of any changes made to the product class, you still have to make changes to the client class to pass zin new values required to create your updated product. This data after all must come from somewhere?
Another example I read stated that once a class is implemented and loads of other classes make use of it directly, changes made to the "product" class here, would require changes to be made to every instantiation of this class, say for example if a new variable was required in its constructor.
From what I can understand, the Factory pattern does make sure the instantiation of this class never changes, if you want to pass a new variable to the products constructor, you simply end up having to pass those new variables to the updated factory instead.
This is therefore clearly not solving the problem but merely moving it and in doing so adds additional complexity.
Given that this is an established pattern, I'm obviously missing something. Hence this post: Please explain to me what I am missing.
Thanks
A Factory is used when you can have many distinct implementations of the same interface, and it is only decided runtime which one the client actually needs. However, the client need not know which implementation it is actually using. This is where the Factory steps in: it encapsulates the details of creating a concrete object and returns it as a generic implementation of the required interface.
There are in fact two distinct patterns associated with the name Factory: Abstract Factory and Factory Method. The latter is used to create instances of a single product, while the former is useful to create a whole family of related products.
A typical example of Abstract Factory is the creation of a family of widgets in a GUI framework. Clients of the framework may only need to know that they are dealing with a window, or a status bar, or a button; however, they need not be tied to the fact whether the actual widget is actually a Windows or MacOS widget. This allows one to create clients which can run on either of these platforms; and in theory, when the framework is ported to a new platform, say, Linux, all what is needed is to implement a new factory which produces all the Linux specific widgets, and plug it in via configuration. Lo and behold, the clients run on Linux without noticing any difference, possibly even without the need to recompile the client code (at least in theory,and in some languages - I know that the reality regarding multiplatform GUIs is different, but this is only an example :-)
Compare this to trying to implement the same without factories: you would have many places within the client code where you needed to decide which platform-specific widget you need to create. And whenever you want to introduce a new family of widgets, you would need to modify each of these places within your code to add a new branch to the many identical switch or if/else blocks. Moreover, since you would be openly dealing with platform-specific widget objects, chances are that some platform-specific widget idiosynchrasies and implementation details would leak out into the client code, thus making it even more difficult to port to other platforms.
the Product instantiation never changes irrespective of any changes made to the product class, you still have to make changes to the client class to pass zin new values required to create your updated product. This data after all must come from somewhere?
Indeed. If the general instantiation process changes, the Factory interface may need to change too accordingly. This is not the point of Factory. Although you can pass in data to the factory at its construction time, which it can then use in the background whenever a new Product is created.
这篇关于为什么工厂模式的工作方式呢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
