将静态方法用作工厂是否被认为是不好的做法？答案

【问题标题】：Is it considered bad practice to use a static method as a factory?将静态方法用作工厂是否被认为是不好的做法？
【发布时间】：2012-09-07 04:04:14
【问题描述】：

我看到大多数项目都创建了单独的工厂类，例如，它们将有一个 User 类和一个 UserFactory 类。如果您的工厂需要更多方法而不仅仅是 CreateUser 方法，这是有道理的，但这些工厂中的大多数只有一个构造函数和一个 CreateUser 方法（或工厂创建的任何等效方法）。那么，除了向类添加静态 User.create() 方法之外，还有其他原因可以创建单独的工厂类吗？

【问题讨论】：

对于严格的模式追随者来说，这一切都不同，但在现实生活中的小项目中并没有那么大。除此之外，拥有一个返回基于接口的对象的单独类是一种很好的做法。这可以在您的测试以及您想要更改实现的任何时候轻松完成。

标签： oop factory-pattern

【解决方案1】：

根据我的经验，如果您经常想要更改实现，则主要使用单独的工厂类，尤其是对于测试用例。例如，如果 User 具有访问数据库的方法并且对于单元测试来说“太慢”，那么您可能希望拥有一个不使用数据库的 MockUser。然后，您可以为实际应用使用 RealUserFactory，并为单元测试使用 MockUserFactory。

但现实世界中可能存在您想要更改的示例，例如从军事规范应用中的 SecurityClearedUser 到另一个应用中的 AnyOldUser。所以一个配置文件会声明工厂的类，例如MilitaryUserFactory 或 AnyOldFactory。

当然，User.create() 可以从配置文件中读取要创建的实际类。所以，在实践中，我不确定是否有那么大的差异。取决于事情是如何设置的。

【讨论】：

【解决方案2】：

要考虑的另一件事是“关注点分离”。在 User.Create 的情况下，用户类将做的比它应该做的更多，因此需要一个能够精确执行此操作的类，即创建一个用户。

通过使用 User.Create，您可以将对象的创建与类本身耦合起来，在其他情况下，您会遇到用户创建由多个步骤组成的场景，如果是这种情况， User.Create 方法变得不合适。

简而言之，让用户对象负责成为用户，并将用户的创建外包给外部关注点，工厂。

从可读性的角度来看，User.Create 与 UserFactory.Create... 将其视为“汽车无法制造汽车”，但工厂可以。

【讨论】：