依赖注入是否意味着您不需要'new'关键字?或者直接创建简单的叶子类如集合是否合理?
在下面的示例中,我注入了比较器,查询和dao,但是SortedSet是直接实例化的:
public IterablegetRecentHires() { SortedSet entries = new TreeSet (comparator); entries.addAll(employeeDao.findAll(query)); return entries; }
Don Branson.. 9
仅仅因为依赖注入是一种有用的模式并不意味着我们将它用于一切.即使使用DI,也经常需要新的.暂时不删除新内容.
仅仅因为依赖注入是一种有用的模式并不意味着我们将它用于一切.即使使用DI,也经常需要新的.暂时不删除新内容.
我通常决定是否使用依赖注入的一种方法是在为被测试类编写单元测试时是否需要模拟或删除协作类.例如,在您的示例中,您(正确地)注入了DAO,因为如果您为类编写单元测试,则可能不希望任何数据实际写入数据库.或者,协作类可能会将文件写入文件系统,或者依赖于外部资源.或者在单元测试中行为是不可预测的或难以解释的.在这些情况下,最好注入这些依赖项.
对于像TreeSet这样的协作类,我通常不会注入那些,因为通常不需要模拟像这样的简单类.
最后要注意的是:当一个字段由于某种原因无法注入时,我仍然想在测试中嘲笑它,我发现Junit-addons PrivateAccessor类有助于将类的私有字段切换为模拟对象由EasyMock(或jMock或您喜欢的任何其他模拟框架)创建.