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

Question

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

Answer 1

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

但是可能有一些现实世界的例子，你想要改变，比如从军用规格应用程序中的SecurityClearedUser到另一个应用程序中的AnyOldUser。所以配置文件会声明工厂的类，例如一个MilitaryUserFactory或一个AnyOldFactory。

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

Answer 2

另一件需要考虑的事情是分离关注点＆＃39;。在User.Create的情况下，用户类将做的比它应该做的更多，因此需要一个完全正确的类，创建一个User。

通过使用User.Create，您可以将对象的创建与类本身相结合，在其他情况下，如果用户创建包含各种步骤，您将遇到方案，如果是这种情况，则User.Create方法变得不合适。

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

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