你能在需要单身的地方使用依赖注入吗?

这可能听起来像一个愚蠢的问题,但DI可以在需要Singleton的地方使用吗?或者是否存在Singleton更有意义的用例?我的一位教授说,有一些但有效的案例,单身人士“足够好”,但我对此不满意: - /。     
已邀请:
DI中的一个主题是将要注入的对象的生命周期。示例生命周期包括Singleton以及Transient,HttpContext,ThreadLocal,Custom等...因此,当使用DI时,您可以将对象指定为Singleton生存期,可以是在应用程序启动时填充的配置类。作为一个单身人士,这似乎是一个很好的课程。 Singleton模式是一个强大的模式,但与所有设计模式一样,当以错误的方式使用时,它们可能弊大于利。 DI和避免使用Singleton也可以提高测试性。 干杯,现在, 安德鲁     
单身人士是一种模式。它经常出现在DI容器中或作为
static
API。我假设你指的是
static
风味。 通过
static
成员暴露的物体为消费者提供尽可能低的摩擦力;这就是他们如此吸引人的原因。依赖注入以不同的方式解决相同的问题(对象访问)。使用DI,依赖关系的生命周期是配置细节,而不是固有的事实。 这是我的另一个答案,它解决了这个问题: 依赖注入&单身设计模式     
只要有可能,我肯定会对单例对象使用依赖注入。即使你不太可能注入除了对象的一个​​特定实现之外的任何东西,使用注入也有很小的缺点,并且有很多潜在的好处。根据我的经验,依赖注入使得阅读代码的人更容易理解依赖关系,使代码更容易重构,提高可测试性,并且通常可以缩短构建时间。 也就是说,我已经遇到了理想情况下我希望使用注入的代码,但是选择不这样做。这里有些例子。 我正在处理一个我无法轻易改变的API。 我正在编写代码,如果我要求客户端注入他们不应该注意的东西,那么API看起来真的很奇怪。这对于一些静态实用程序库来说是正确的,比如解析字符串的函数,其中我有一个我不希望用户知道的辅助对象。我通常会尽量避免这种情况。 我正在编写实验代码,我将要扔掉。在这种情况下,我会经常采用快捷方式来快速完成某些工作,同时理解代码应该在以后删除或重构。 如果您尚未使用它们,则可能需要检查依赖项注入框架。我很高兴在Java代码中使用Google Guice。     

要回复问题请先登录注册