通过Guice学习理解依赖注入.docxVIP

通过Guice学习理解依赖注入 提及依赖注入（Dependency Injection），想必童鞋们会想到 HYPERLINK / Martin Fowler的《Inversion of Control Containers and the Dependency Injection pattern》，而本文正是通过Guice来学习理解依赖注入的实现。 其次笔者在学习依赖注入之初（未曾学习《Inversion of Control Containers and the Dependency Injection pattern》时），亦曾受“控制反转”（Inversion of Control）和“依赖注入”（Dependency Injection）二概念所蒙蔽。因此为打消各位童鞋学习顾虑，此处给出明确说明，在 HYPERLINK / Martin Fowler未成《Inversion of Control Containers and the Dependency Injection pattern》一文前，开源社区几位轻量级容器作者称其为“控制反转”（Inversion of Control，简称IoC），但由于该名称太泛，常常会让人迷惑，因此 HYPERLINK / Martin Fowler和多位IoC爱好者??论后，决定将这个模式叫做“依赖注入”（ Dependency Injection）。这里可以简单理解为“控制反转”和“依赖注入”只是称谓的不同罢了。 依赖示例  HYPERLINK / Martin Fowler在《Inversion of Control Containers and the Dependency Injection pattern》一文中提供了一个提供一份电影清单组件的例子，伪代码清单1如下： /*finder服务接口*/ public interface MovieFinder { List findAll(); } /*finder服务的消费者*/ public class MovieLister { public Movie[] moviesDirectedBy(String arg) { List allMovies = finder.findAll(); for (Iterator it = allMovies.iterator(); it.hasNext();) { Movie movie = (Movie) it.next(); if (!movie.getDirector().equals(arg)) it.remove(); } return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]); } /*指向具体服务类型的实体对象*/ private MovieFinder finder; public MovieLister() { finder = new ColonDelimitedMovieFinder(movies1.txt); } } 清单1 从清单1的伪代码中我们可以看出在涉及到实际寻找影片时，MovieLister类就会涉及到MovieFinder 的某个具体子Finder（电影查找器）类，MovieLister类会在构造子中直接创建MovieFinder的实例，因此MovieLister类和MovieFinder会存在如图1所示的依赖关系： 图1 图1中MovieLister 类既依赖于MovieFinder接口，又依赖于MovieFinder接口的具体实现类（ColonDelimitedMovieFinder），这就会使得电影清单组件会因为在不同的应用场景中它所依赖的电影查找器可能是千差万别的。所以我们希望MovieLister 类只依赖于接口，因此我们就需要有一种机制能同时满足如下两个要求： 解除电影清单中对MovieFinder类型的编译时依赖； 在运行时为电影清单提供所需的MovieFinder类型实例。 换句话说就是在运行时建立电影清单组件中对MovieFinder所需的依赖关系，从而使其电影清单组件在编译时对MovieFinder的依赖推迟到运行时。 依赖关系在面向对象的程序中是广泛存在的，只要A类型中用到了B类型实例，那么A就依赖于B。依赖示例谈到的内容是把概念抽象到了服务消费者和服务提供者的角度，这也符合现在SOA的设计思路。从另一种抽象方式上来看，可以把电影清单看成我们要构建的主系统，而MovieFinder是系统中的plugin，主系统并不强依赖于任何一个插件，但一旦插件被加载，主系统