这取决于。
表现
如果您想像这里一样评估两个抽象选项之间的性能差异;最好的方法是夸大一切的规模。例如,假设SomeObject
实例化需要大量时间(例如,600 秒),并且您计划调用method()
很多(因为性能问题通常要等到项目规模扩大后才会意识到)。
很明显:选项 1 将在多次method()
调用中“执行”得更好,因为选项 2 每次您想要调用方法时都会导致巨大的操作。(是的,作为一个粗略的性能测试,您可以通过 for 循环运行每个选项并比较经过的时间,但应该很容易看出:所有其他条件都相同,创建对象 n 次将比创建对象花费更多时间一个对象一次)。
但在夸张的例子中,表现本身并不一定是在所有情况下都支持选项 1 的理由。
建筑学
选项 2
这真的归结为SomeObject
. 是 什么SomeObject
?这可能SomeObject
是一个您无法在 ; 的生命周期内保持打开状态的对象A
;例如,它可能是某种流读取器,它在从流中读取资源时锁定资源。在这种情况下,您可能不想一直SomeObject
“打开”阻塞该资源;它应该在通话结束时处理。method()
选项1
好吧,但也许SomeObject
是暴露业务逻辑的服务或外观。正如您在问题中提到的那样,它“更适合测试”,完整的答案是,是的,它为依赖注入提供了一个更简单的钩子,这是单元测试的关键组成部分。(虽然,通常它会被重写为private SomeObject a;
,构造函数喜欢public a (SomeObject a) { this.a = a; }
遵循控制范式的依赖注入/反转。但是,对于这个问题的目的,最终结果是相同的。)
对于(设计良好的)服务或实用程序功能,您希望它自己(私下)处理对象处置。在这种情况下,更常用的模式是选项 1,因为它为您提供了一个管理依赖关系的地方,而不是在每个使用它的方法中。
你的选择
了解以上内容就足以做出明智的决定。
- 选项 1 - 服务、立面、实用程序等。
- 选项 2 - 需要处理的对象;实现
Closable
, StreamReader
, FileWriter
, 等的对象