Gin*_*eer 3 design-patterns factory-pattern
我从来没有真正看过工厂模式,今天决定花时间根据这篇文章(http://msdn.microsoft.com/en-us/library/ee817667.aspx)创建一个快速示例,最后让我的头围绕它.
源代码完美地安排在三个单独的程序集中,整齐地命名为Product,Factory和Client.
Factory模式的主要优点(据我所知)是从"Client"类抽象"product"类的实例化.因此,在提供的示例中,无论是否对产品类进行任何更改,Product实例化都不会更改,您仍然必须对客户端类进行更改以传递创建更新产品所需的新值.毕竟这个数据必须来自某个地方？
我读到的另一个例子表明,一旦实现了一个类并且其他类的负载直接使用它,在这里对"product"类所做的更改将需要对该类的每个实例化进行更改,例如,如果构造函数中需要新变量.
根据我的理解,Factory模式确保此类的实例化永远不会更改,如果要将新变量传递给product构造函数,您最终必须将这些新变量传递给更新的工厂.
因此,这显然不能解决问题,而只是移动它并且这样做会增加额外的复杂性.
鉴于这是一种既定的模式,我显然错过了一些东西.因此这篇文章:请向我解释我错过了什么.
谢谢
当您可以拥有相同接口的许多不同实现时,将使用Factory,并且仅确定客户端实际需要的运行时间.但是,客户端不需要知道它实际使用的是哪个实现.这是工厂介入的地方:它封装了创建具体对象的细节,并将其作为所需接口的通用实现返回.
实际上有两个与名称Factory相关的不同模式:抽象工厂和工厂方法.后者用于创建单个产品的实例,而前者用于创建整个相关产品系列.
Abstract Factory的典型示例是在GUI框架中创建一系列小部件.框架的客户端可能只需要知道他们正在处理窗口,状态栏或按钮; 但是,它们无需与实际的小部件实际上是Windows或MacOS小部件相关联.这允许人们创建可以在这些平台上运行的客户端; 理论上,当框架移植到一个新平台,比如Linux时,所需要的只是实现一个新工厂,生成所有Linux特定的小部件,并通过配置插入它.请注意,客户端在Linux上运行时没有注意到任何差异,甚至可能无需重新编译客户端代码(至少在理论上,在某些语言中 - 我知道关于多平台GUI的现实是不同的,但这只是一个例子 :-)
相比之下,尝试在没有工厂的情况下实现相同的功能:您需要在客户端代码中有许多位置,您需要决定需要创建哪个特定于平台的小部件.每当您想要引入一个新的小部件系列时,您需要修改代码中的每个位置,以便为许多相同switch或if/else块添加新分支.此外,由于您将公开处理特定于平台的窗口小部件对象,因此某些特定于平台的窗口小部件特性和实现细节可能会泄漏到客户端代码中,从而使得移植到其他平台变得更加困难.
无论对产品类进行任何更改,产品实例化都不会更改,您仍需要对客户端类进行更改以传递创建更新产品所需的新值.毕竟这个数据必须来自某个地方？
确实.如果常规实例化过程发生更改,则Factory接口可能也需要相应更改.这不是工厂的重点.虽然您可以在构造时将数据传递到工厂,然后可以在创建新产品时在后台使用它.