为什么要使用工厂类而不是直接对象构造？

#1 楼

工厂类之所以被实施是因为它们使项目更紧密地遵循SOLID原则。特别是，接口隔离和依赖关系反转的原理。

功能和接口可以提供更多的长期灵活性。它允许更解耦的设计，因此更易于测试。这是为什么您会走这条路的非详尽清单：


它使您可以轻松地引入控制反转（IoC）容器
它使您的代码可以模拟接口，因此更具可测试性
在更改应用程序时，它可以为您提供更大的灵活性（例如，您可以创建新的实现而无需更改相关代码）

请考虑这种情况。

组件A（->取决于）：

Class A -> Class B
Class A -> Class C
Class B -> Class D

我想将B类移至组件B，这取决于程序集A。有了这些具体的依赖关系，我必须在整个类层次结构中移动大部分。如果使用接口，则可以避免很多麻烦。

组装A：

Class A -> Interface IB
Class A -> Interface IC
Class B -> Interface IB
Class C -> Interface IC
Class B -> Interface ID
Class D -> Interface ID

我现在可以将B类转移到组装中B没有任何疼痛。它仍然取决于程序集A中的接口。

使用IoC容器来解决依赖关系将为您提供更大的灵活性。更改类的依赖关系时，无需更新对构造函数的每次调用。

遵循接口隔离原理和依赖关系反转原理，我们可以构建高度灵活的，分离的应用程序。一旦您使用了其中一种类型的应用程序，您将再也不想回到使用new关键字了。

#2 楼

就像whatsisname所说的那样，我相信这是货物崇拜软件设计的案例。工厂，尤其是抽象工厂，仅在您的模块创建一个类的多个实例并且您想使该模块的用户能够指定要创建的类型时才可用。这个要求实际上很少见，因为在大多数情况下，您只需要一个实例，并且可以直接传递该实例，而不用创建一个显式工厂。

问题是，工厂（和单例）是极其容易实现，因此人们在不需要它们的地方也经常使用它们。因此，当程序员认为“我应该在此代码中使用哪些设计模式？”时，

创建许多工厂的原因在于“也许，有一天，我将需要以不同的方式创建这些类”。明显违反了YAGNI。

引入IoC框架时，工厂变得过时了，因为IoC只是一种工厂。而且许多IoC框架都可以创建特定工厂的实现。

此外，也没有设计模式可以使用CreateXXX方法创建大型静态类，而这些静态类仅调用构造函数。而且它尤其不被称为工厂（也不叫抽象工厂）。

#3 楼

工厂模式的流行源于“ C风格”语言（C / C ++，C＃，Java）的编码人员中几乎信条的信念，即使用“ new”关键字是不好的，应不惜一切代价避免使用（或最不集中）。反过来，这来自对单一职责原则（SOLID的“ S”）以及对依赖关系倒置原则（“ D”）的超严格解释。简而言之，SRP表示理想情况下，一个代码对象应该有一个“更改理由”，并且只有一个。 “更改原因”是该对象的主要目的，它在代码库中的“职责”，以及需要更改代码的任何其他内容都不需要打开该类文件。 DIP甚至更简单。代码对象永远不应该依赖于另一个具体对象，而应该依赖于抽象。

举例来说，通过使用“ new”和公共构造函数，您可以将调用代码耦合到特定的构造上。具体具体类别的方法。您的代码现在必须知道类MyFooObject存在，并且具有接受字符串和int的构造函数。如果该构造函数需要更多信息，则必须更新该构造函数的所有用法以传递该信息，包括您现在正在编写的信息，因此要求它们具有有效的传递对象，因此，它们必须具有或对其进行更改以获取它（将更多责任添加到使用对象）。另外，如果在代码库中曾经用BetterFooObject替换MyFooObject，则必须更改旧类的所有用法以构造新对象，而不是旧对象。

因此，相反，MyFooObject的所有使用者都应直接依赖于“ IFooObject”，它定义了实现包括MyFooObject在内的类的行为。现在，IFooObject的使用者不能仅构造IFooObject（无需知道特定的具体类是IFooObject，而他们不需要），因此必须为他们提供IFooObject实现类或方法的实例。

现在，这是理论与现实相遇的地方；从外部，由另一个对象负责了解如何为这种情况创建正确的IFooObject。在我们看来，该对象通常称为工厂。一个对象永远不会一直对所有类型的更改都关闭。举例来说，IFooObject现在是代码库中的另一个代码对象，只要使用者或IFooObjects的实现所需的接口发生更改，该对象就必须更改。这就引入了新的复杂度，涉及跨此抽象更改对象彼此交互的方式。此外，如果接口本身被新的接口取代，消费者仍将不得不做出更深层次的改变。

一个好的编码员知道如何平衡YAGNI（“您将不需要它“）使用SOLID，可以通过分析设计并找到很有可能需要以特定方式进行更改的地点，并对其进行重构以使其更能容忍这种类型的更改，因为在这种情况下，“您将需要它”。

#4 楼

当构造函数包含简短的简单代码时，它们就很好了。

当初始化不仅仅是为字段分配几个变量时，工厂就有意义了。这里有一些好处：在专用类（工厂）中，长而复杂的代码更有意义。如果将相同的代码放入调用大量静态方法的构造函数中，则会污染主类。
在某些语言和某些情况下，在构造函数中引发异常是一个非常糟糕的主意，因为它可能会引入错误。
调用构造函数时，调用者需要知道要创建的实例的确切类型。并非总是这种情况（作为Feeder，我只需要构造Animal即可提供它；我不在乎它是Dog还是Cat）。

#5 楼

如果使用接口，则可以独立于实际实现。可以配置工厂（通过属性，参数或其他方法）以实例化许多不同的实现中的一个。

一个简单的示例：您想与设备进行通信，但您不知道如果将通过以太网，COM或USB。您定义一个接口和3个实现。在运行时，您可以选择所需的方法，然后工厂将为您提供适当的实现。

经常使用它...

#6 楼

这是Java / C＃模块系统中存在限制的征兆。

原则上，没有理由您不应该将具有相同构造函数和方法签名的类的一种实现换成另一种实现。 。有一些语言允许这样做。但是，Java和C＃坚持每个类都有唯一的标识符（全限定名），并且客户端代码最终以硬编码依赖于此。

您可以通过以下方式来解决此问题摆弄文件系统和编译器选项，以便com.example.Foo映射到其他文件，但这是令人惊讶且不直观的。即使这样做，您的代码仍然只与该类的一种实现联系在一起。即如果编写依赖于类Foo的类MySet，则可以在编译时选择MySet的实现，但仍无法使用Foo的两种不同实现来实例化MySet。

这种不幸的设计决策迫使人们不必要地使用interface来对代码进行未来验证，以防止他们以后需要对某些内容进行不同的实现或促进单元测试。这并不总是可行的。如果您有任何方法可以查看该类的两个实例的私有字段，则将无法在接口中实现它们。例如，这就是为什么您在Java的union接口中看不到Set的原因。尽管如此，在数字类型和集合之外，二进制方法并不常见，因此您通常可以避免使用它。

当然，如果调用new Foo(...)，您仍然对类有依赖性，因此如果您希望类能够直接实例化接口，则需要工厂。但是，通常最好的方法是在构造函数中接受该实例，然后让其他人决定使用哪个实现。

由您决定是否值得使用接口和工厂来膨胀代码库。一方面，如果所讨论的类在您的代码库内部，则重构代码以使其将来使用其他类或接口是微不足道的；否则，请执行以下操作。您可以在发生这种情况时调用YAGNI并稍后进行重构。但是，如果该类是您已发布的库的公共API的一部分，则无法选择修复客户端代码。如果您不使用interface，以后又需要多个实现，那么您将陷入困境。

#7 楼

在我看来，他们只是使用简单工厂，这不是正确的设计模式，不应与抽象工厂或工厂方法相混淆。

由于他们创建了“巨大的带有数千个CreateXXX静态方法的fabric类”，这听起来像是一种反模式（也许是上帝类？）。

我认为Simple Factory和static creator方法（不需要外部方法）类），在某些情况下会很有用。例如，当对象的构造需要各种步骤时，例如实例化其他对象（例如，有利于合成）。

我什至不称其为Factory，而只是将一堆封装在带有后缀“ Factory”的随机类中的方法。

#8 楼

作为库的用户，如果库具有工厂方法，则应使用它们。您将假定工厂方法使库的作者可以灵活地进行某些更改而不会影响您的代码。例如，他们可能会在工厂方法中返回某个子类的实例，而该方法无法使用简单的构造函数。

作为库的创建者，如果您想自己使用这种灵活性，则可以使用工厂方法。

在您描述的情况下，您似乎有一种印象，就是用工厂方法代替构造函数是没有意义的。对于参与其中的每个人来说，这无疑是痛苦的。没有充分的理由，库就不应从其API中删除任何内容。因此，如果我添加了工厂方法，我将使现有的构造函数可用（也许已弃用），直到工厂方法不再只是调用该构造函数并且使用普通构造函数的代码效果不如预期为止。您的印象很可能是正确的。

#9 楼

在Scala和函数式编程时代，这似乎已经过时了。功能的坚实基础取代了庞大的类。

还要注意，Java的双{{在使用工厂时不再起作用，即

someFunction(new someObject() {{
    setSomeParam(...);
    etc..
}})

这可以让您创建一个匿名类并对其进行自定义。

由于快速的CPU，功能性编程可以缩小空间，即代码大小，因此在时间空间难题中，时间因数已经大大缩小了。现在很实用。