基于Eclipse RCP简化IoC实现

　　一. 引言

　　Eclipse富客户端平台（RCP）是一个强有力的软件基础库-它基于相互联系的协作性插件，允许开发者构建普通应用程序。借助于RCP，开发者只需专注于应用程序业务代码的开发而不必花时间去重写应用程序管理逻辑。

　　控制反转（IoC）和依赖性注入（DI）都是能够用来减少程序之间的耦合度的编程模式。它们都遵循一种简单的原则：你不必创建自己的对象，而只需描述该对象如何被创建；你不必实例化或直接定位你的组件需要的服务，而只需确定哪些服务为哪些组件所需要，然后由其它程序（通常是一个容器）负责把它们"钩"到一起。这就是著名的"好莱坞原则"-不要找我们，让我们找你好了。

　　本文将描述一种把依赖性注入支持功能加入到一个Eclipse RCP应用程序中的简单方法。为了避免影响Eclipse平台基本结构并且为了把IoC框架透明地添加到RCP，我们将联合使用运行时刻字节码操作技术（使用ObjectWeb ASM库），Java类加载代理（使用java.lang.instrument包）和Java注解技术。

　　二. 什么是Eclipse丰富客户端平台？

　　用一句话来概括，Eclipse富客户端平台就是用于构建既能独立运行又能在网络中运行的应用程序的一组库，软件框架及一个运行时刻环境。

　　尽管Eclipse被作为一种开发程序的IDE来使用；但是，整个软件自从3.0版发行以来被重新构建成各种独立的组件，以便可以使用这些组件的最小子集来构建任意的应用程序。这样的一个子集构成了丰富客户端平台并且包括不同的元素：基本运行时刻，用户接口组件（SWT和JFace），插件，还有OSGi层。图1展示了Eclipse平台的主要组件构成。

图1.Eclipse平台的主要构成组件

　　整个Eclipse平台基于两个关键概念-插件和扩展点。一个插件是一个小的功能单元，它能够被独立地开发和发布。典型情况下，插件被打包为一个jar文件，并且能够通过添加某种功能来扩展Eclipse平台（例如，一个编辑器，一个工具栏按钮或一个编译器）。其实，整个Eclipse平台就是一组相互连接的彼此之间能够进行通讯的插件。一个扩展点是一个可用的连接点，其它的插件可以用来提供添加的功能（用术语来说，就是"扩展"）。扩展和扩展点都是在与插件绑定到一起的XML配置文件中定义的。

　　尽管插件机制利用了重要的模式-例如关系分离，强连接等等；但是，插件需要的通讯能够导致这些插件间的物理依赖性。典型的例子就是，插件需要定位可用于应用程序的单例（singleton）服务-例如数据库连接池，日志处理或用户保存的收藏信息。控制反转和依赖性注入都是去除这种依赖性的可行方案。

　　三. 控制反转和依赖性注入

　　控制反转是一种编程模式-主要目的是实现服务(或应用程序组件)的定义方式与这些服务应该怎样定位自己依赖的其它服务之间的分离。

　　为了实现分离，其实现通常依赖于一个容器或定位符框架-由它们来负责各种具体的任务：

　　· 保持一组可用的服务

　　· 提供一种方式把组件（即"可服务的对象"）与其依赖的服务绑定到一起

　　· 为应用程序代码提供一种方式以请求一个配置好的对象（也就是说，一个其依赖性都得到满足的对象）-这可以确保所有相关的服务都可用于该对象

　　实际上，目前的框架基本都是使用三种基本技术的组合来实现服务与组件之间的绑定的：

　　· 类型1(基于接口)：可服务的对象需要实现一个专用接口-由这个接口提供给这些对象一个它们能够查找依赖性(其它服务)的对象。这是Excalibur所提供的早期容器使用的模式。

　　· 类型2（基于setter）：服务被经由JavaBeans属性(setter方法)赋给可服务的对象。例如，HiveMind和Spring都使用这种方法。

　　· 类型3（基于构造器）：服务被提供为构造器参数(并不被暴露为JavaBeans属性)。这是一种由PicoContainer专用的独特的方法。另外，它也用于HiveMind和Spring中。

　　我们将采纳类型2的一种变体-通过注解的方法提供服务。一种声明一个依赖性的方法可以如下实现：

@Injected public void aServicingMethod(　 　Service s1，AnotherService s2) { 　　//把s1和s2保存到类变量中 　　//以便在需要时使用它们 }

　　控制反转容器将查找注入的注解并且调用要求的参数来调用该方法。为了把IoC加入到Eclipse平台中，我们把在服务和可服务的对象之间进行绑定的代码打包为一个Eclipse插件。该插件定义一个扩展点（名为com.onjava.servicelocator.servicefactory）-它可以用来为应用程序提供服务工厂。无论何时当一个可服务的对象需要配置时，该插件将请求到一个工厂的服务实例。ServiceLocator类负责实现所有这些工作，正如下面的代码片断所描述的（我们跳过处理分析扩展点的代码-因为这些代码非常直接）：

/** *把要求的依赖性注入到参数对象中。它扫描可服务的对象-通过查找标识有{@link Injected}注解的方法。参数类型是从匹配的方法中提取的。每一种类型的实例是从注册的工厂中创建的（见{@link IServiceFactory}）。相应于所有参数类型的实例都被创建完毕，该方法被调用，并继续检查下一个方法。 * * @param-要被服务的可服务对象 * @抛出ServiceException异常 */ public static void service(Object serviceable) throws ServiceException { 　ServiceLocator sl = getInstance(); 　if (sl.isAlreadyServiced(serviceable)) { 　　//避免多次初始化问题-由于存在构造器分层 　　System.out.println("Object " +serviceable + " has already been configured "); 　　return; 　} 　System.out.println("Configuring " + serviceable); 　//为请求的服务分析类 　for (Method m : serviceable.getClass().getMethods()) { 　　boolean skip=false; 　　Injected ann=m.getAnnotation(Injected.class); 　　if (ann != null) { 　　　Object[] services = new Object[m.getParameterTypes().length]; 　　　int i = 0; 　　　for(Class＜?＞ klass :m.getParameterTypes()){ 　　　　IServiceFactory factory = sl.getFactory(klass，ann.optional()); 　　　　if (factory == null) { 　　　　　skip = true; 　　　　　break;　 　　　　} 　　　　Object service = factory.getServiceInstance(); 　　　　//检查：确保返回的服务的类是从该方法中盼望的那一个 　　　　assert(service.getClass().equals(klass) || klass.isAssignableFrom(service.getClass())); 　　　　services[i++] = service ; 　　　} 　　　try { 　　　　if (!skip) 　　　　　m.invoke(serviceable， services); 　　　} 　　　catch(IllegalAccessException iae) { 　　　　if (!ann.optional()) 　　　　　throw new ServiceException("Unable to initialize services on " + 　　　　　　　serviceable + 　　　　　　　": " + iae.getMessage()，iae); 　　　} 　　　catch(InvocationTargetException ite) { 　　　　if (!ann.optional()) 　　　　　throw new ServiceException("Unable to initialize services on " + 　　　　　　　serviceable + ": " + ite.getMessage()，ite); 　　　} 　　} 　} 　sl.setAsServiced(serviceable); }

　　既然由该服务工厂返回的服务也可能是可服务的；所以，这种策略允许定义服务层次（即嵌套的服务）（但是，目的还不支持循环依赖性）。