除了子类化之外，工厂方法模式有什么好处？

Question

在使用.NET Color结构时，我发现自己想知道为什么Microsoft选择对这个结构使用工厂方法模式（知道工厂方法模式主要用于子类化，并且结构不能被子类化）。

我尝试了维基百科。它确认了我的想法，但实际上没有给出答案：

  

虽然工厂方法模式背后的动机是允许的   子类选择要创建的对象类型，还有其他类型   使用工厂方法的好处，其中许多不依赖于   子类。因此，通常定义“工厂方法”   为了获得这些对象，创建对象不是多态的   好处。这些方法通常是静态的。

那么，请告诉我，工厂方法模式的其他好处是什么？

例如，如何通过调用Color myColor = Color.FromArgb(255,255,255)代替Color myColor = new Color(255,255,255)来获益？

（请注意，第二种方法实际上是不可能的，因为Point结构没有参数化构造函数，因为它使用了工厂方法模式）

Answer 1

通常使用软件，通常使用工厂来减少依赖关系。只有工厂需要知道它可以创建的所有类型，它必须应用的转换，并且可以从客户端抽象许多依赖项 - 处理工厂的客户端不需要查看每种类型的工厂的接口可能会创造。

由于语言的解释和编译方式不同，这对某些语言的影响要大于其他语言。因此，抽象工厂可以隐藏其界面背后的整个库。

所以CodeInChaos指出它在这种情况下确实是一个命名构造函数 - 但是可能仍然存在物理依赖，在这种情况下可以抽象出来吗？ 是<！/ strong>即可。让我们使用颜色创建一个示例场景。

假设有一个定义颜色的类。这个类有多个特化和不同的成员，以准确地表示可用颜色的每个专业化 - 比如灰度，RGB和CMYK。天真的转换方法已经能够产生非法颜色。使用工厂方法，您可以使用类型通过请求颜色模型转换任意颜色的类型来抽象该复杂性。也就是说，RGBA转换为灰度的转换是一个功能，CMYK到RGBA的转换是另一个功能。抽象颜色表示可能有一个名为asRGBA()的方法来处理此转换，其中每个特化或子类型可能提供完全不同的转换实现。

好吧，这抽象了一些复杂性并保持我们所有的颜色合法（RGB不能代表所有CMYK值）。似乎过于复杂了？ 否即可。实际上，有更多的颜色表示。同样，存在可以特定于设备（例如监视器）的颜色配置文件，或者特定于其他目标（例如，连接的打印机）的颜色配置文件。这些配置文件的转换功能要复杂得多。

对于基本颜色表示，我们必须注入许多依赖项来处理所有这些设备和目标。精心设计的工厂方法可以抽象所有这些并使用优化的实现来实现这些转换，同时减少依赖性。

这是一个人为的例子（我不是C＃dev），但它确实说明了如何使用工厂方法来降低复杂性并最大限度地减少依赖性。

Answer 2

我使用这种方法的主要原因是因为它们实际上是命名的构造函数。例如，对于Color，如果没有名称，则指定组件的顺序并不明显。通常会使用ARGB，但有时您也会看到BGRA或甚至是HSV这样完全不同的颜色空间。将使用过的颜色顺序放入方法名称中，使代码更加自我记录。

另一个优点是静态方法支持类型推断。例如，使用Tuple<...>，您只需使用Tuple.Create(1,5)代替更详细的new Tuple<int,int>(1,5)。

Answer 3

来自msdn的引用暗示了一个目的：

  

使用new运算符创建struct对象时，会创建它并调用相应的构造函数。与类不同，可以在不使用new运算符的情况下实例化结构。如果不使用new，则字段将保持未分配状态，并且在初始化所有字段之前无法使用该对象。

工厂方法模式，在.NET结构的上下文中，阻止未初始化的实例。

Answer 4

你能解释一下吗？ Color结构的实现的哪个部分是工厂？

此外，您似乎与“工厂”AKA（抽象工厂）和“工厂方法”模式不匹配。两者都是创作模式。但它们不同，用于不同的目的。

参考

http://en.wikipedia.org/wiki/Software_design_pattern

Answer 5

我认为术语“工厂方法”通常不会用于引用返回结构的方法，因为返回结构的所有方法都返回一个之前不存在的实例（具有讽刺意味的是，从vb.net调用的struct构造函数）。