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

EN

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

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

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

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

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

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

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