依赖注入的方式以及优缺点

依赖注入的三种方式以及优缺点。

• 博客分类： 
• 设计模式
• IOC

 

依赖注入是指在创建一个对象时，自动地创建它依赖的对象，并注入。
大家都知道有三种途径来实现依赖注入，我这里总结一下这三种方式的优缺点：

 

1.构造方法注入:

优点：

• 在构造方法中体现出对其他类的依赖，一眼就能看出这个类需要其他那些类才能工作。
• 脱离了IOC框架，这个类仍然可以工作，POJO的概念。
• 一旦对象初始化成功了，这个对象的状态肯定是正确的。

缺点：

• 构造函数会有很多参数（Bad smell）。
• 有些类是需要默认构造函数的，比如MVC框架的Controller类，一旦使用构造函数注入，就无法使用默认构造函数。
• 这个类里面的有些方法并不需要用到这些依赖（Bad smell）。

2.  Set方法注入：

优点：

• 在对象的整个生命周期内，可以随时动态的改变依赖。
• 非常灵活。

缺点：

• 对象在创建后，被设置依赖对象之前这段时间状态是不对的。
• 不直观，无法清晰地表示哪些属性是必须的。

3. 方法参数注入：

方法参数注入的意思是在创建对象后，通过自动调用某个方法来注入依赖。类似如下代码。

Java代码  

1. public class MovieRecommender {  
2.   
3.   private MovieCatalog movieCatalog;  
4.   
5.   private CustomerPreferenceDao customerPreferenceDao;  
6.   
7.   @Autowired  
8.   public void prepare(MovieCatalog movieCatalog,  
9.                       CustomerPreferenceDao customerPreferenceDao) {  
10.       this.movieCatalog = movieCatalog;  
11.       this.customerPreferenceDao = customerPreferenceDao;  
12.   }  
13.   
14.   // ...  
15. }  

这种方式介于Set方法注入和构造方法注入之间。比如说我们通常会用一个Init方法来接受依赖的参数。

这种方法可能不太常用，一般是只有一个方法依赖到注入的对象时用到，如果有多个方法依赖到注入的对象，还是比较倾向于使用构造方法注入。

优点：

• 比较灵活。

缺点：

• 新加入依赖时会破坏原有的方法签名，如果这个方法已经被其他很多模块用到就很麻烦。
• 与构造方法注入一样，会有很多参数。

我个人很不倾向于在业务逻辑层中应用Autowired 或者是 Inject这样的annotation（Attribute）来实现注入，因为一旦脱离了IOC框架，代码就无法重用了。