我们是否应该始终使用工厂而不是使用'new'关键字创建对象？

Question

我在很多地方都读过，通常应该避免使用'new'关键字创建对象。在任何情况下，直接在客户端代码中创建对象比使用工厂类更好的主意吗？

Answer 1

工厂的重点是将对象创建与对象使用（业务逻辑）分开。通常认为这是一种好习惯，因为它有助于实现关注分离和单一责任

等原则。

另一方面，工厂生产间接费用。如果使用它们，则必须编写（或阅读）更多代码。

我确信在某些情况下工厂没有用处。我想到的一种情况是UI编程中使用的动作侦听器类。

一如既往，您必须决定每种情况。只是问自己一个问题：它将使我的代码更易于阅读和修改吗？

您还应该区分仅产生少量开销的静态工厂方法和复杂得多的抽象工厂。

Answer 2

Factory方法允许类将实例化延迟到子类。因此，当抽象类的实现经常更改时，最好使用它。如果您不处理具有多个实现的抽象类。

Answer 3

  

我在许多地方都读过使用'new'关键字创建对象   一般应避免使用

那是设计对象创建的一种极端愿景。
在合理的情况下，应优先使用工厂方法（公共static方法）而不是公共构造方法。
此外，在某些其他情况下，构建器模式比它们更合适。

我认为您应该从类的使用角度来思考这个问题。
公开一个公共构造函数意味着公开一个特定的实现，而该实现不可能在不破坏API且不强迫客户端更改其代码的情况下为客户端更改内部（实现，缓存，计算或任何东西）。

如果该类公开给不同的客户，通常您不想公开该类的公共构造函数，因为您不想在以后破坏其现有代码并且不想保留缺陷/现有实施中的问题。

如果该类是项目的内部类，则仅当该类现在具有值时，才应添加复杂性以在该类中定义工厂或构建器。
如果不是这种情况，因为这是内部原因，您可以随时重构您的应用程序的代码以使用新方法。您不会破坏多个客户代码。

  

是否存在直接在客户端代码中创建对象的情况   有比使用工厂类更好的主意吗？

除了用法字段外，我还可以引用服务类或实体类作为公共构造函数的良好候选者。
贫血模型和逐层模型（例如DTO）也是支持公共构造函数的不错选择。逻辑和一致性由操作它的服务来确保。