java - 什么时候使用工厂而不是简单地返回一个 bean 是一个糟糕的设计选择？

Question

我们的应用程序大量使用工厂来吐出对象，但我经常想知道它们是否总是真的有必要，并且将“已知对象”的实例创建为 bean 并不会更好。争论的焦点是开发人员经常定制这些返回对象的实现(这些对象与它们的接口(interface)类型一起返回)，并且由于我们在技术上并不“知道”我们到底得到了什么，所以最好使用工厂。我现在需要创建一个工厂，这需要接口(interface)、类实现，然后是工厂。不过，我的对象不会改变——它确实是一个具有特定用途的具体对象……我不应该只实例化一个获取和设置状态的 bean 吗？我试图避免过早的概括。

Answer 1

工厂或依赖注入(inject)解决方案的全部目的是减少客户端和对象的运行时类型之间的耦合。的确，客户端必须知道接口(interface)和数据源，但现在源可以自由返回实现该接口(interface)的任何类型。它还允许您将运行时类型的知识封装在一个地方——只有工厂或依赖注入(inject)解决方案需要知道。

这在生成运行时代理以实现声明式事务时很有用。从客户的角度来看，他们正在处理界面。工厂可以生成为客户端管理事务的代理。

一旦您键入“new”，客户端就会在运行时使用编译类型。改变它意味着改变客户。如果您在代码中有很多地方调用“new”，这可能是一个维护问题。

什么时候叫“new”？我认为在方法内部实例化本地对象是合适的，当它们超出范围时将被 GC。该方法创建它们，使用它们，然后它们就完成了。我不会在那里使用工厂或 DI 解决方案。

也许你应该关闭你的工厂并考虑依赖注入(inject)解决方案，如 Spring、Guice 或 PicoContainer。