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

EN

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

另一个优点是静态方法支持类型推断。例如，对于Tuple<...>，您可以简单地使用Tuple.Create(1,5)而不是更冗长的new Tuple<int,int>(1,5)。

你能解释更多吗？实现颜色结构的哪个部分是工厂？

而且，您似乎与“工厂”AKA (抽象工厂)和“工厂方法”模式不匹配。两者都是创造模式。但它们是不同的，并被用于不同的目的。

参考

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

对于一般的软件，工厂通常被用来减少依赖。只有工厂需要知道它可以创建的所有类型，它必须应用的转换，并且许多依赖项可以从客户机中抽象出来--处理工厂的客户端不需要查看工厂可能创建的每个类型的接口。

由于语言的解释和编译非常不同，这对某些语言的影响比其他语言更大。因此，抽象工厂可以将整个库隐藏在其接口后面。

因此，CodeInChaos指出，在这种情况下，它确实是一个命名的构造函数--但是，在这个场景中，是否仍然存在可以抽象的物理依赖呢？，是的，。让我们使用颜色创建一个示例场景。

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

好吧，这抽象了一些复杂性，并使我们所有的颜色都是合法的(RGB不能表示所有的CMYK值)。看起来太复杂了？No。在现实中，有更多的颜色表示。此外，还有一些颜色配置文件可以是特定于设备(例如监视器)，也可以是特定于其他目标(例如，连接的打印机)。这些概要文件的转换函数要复杂得多。

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

这是一个人为的例子(我不是C#开发人员)，但它确实说明了如何使用工厂方法来降低复杂性和最小化依赖关系。