一. 引言

　　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); }

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

　　前一节所描述的各种注入策略通常都依靠存在一个容器来提供一个空的入口点-应用程序用来请求正确配置的对象。然而，在开发我们的ioc插件时，我们想维护一种透明的方法-这主要基于下面两个理由：

　　? rcp采用复杂的类加载器和实例化策略来保持插件独立性和强制实施可见性约束。我们并不想修改或替换这样的策略来引入我们的基于容器的初始化规则。

　　? 显式地引用这样一个入口点(在我们例子中，是指定义在service locator插件中的service()方法)将强迫应用程序开发者采用一种显式的模式和逻辑来检索初始化的组件。这意味着，在应用程序代码中存在某种库锁定。因此，我们要定义一个并不需要一种显式的引用它的codebase的协作性插件。

　　由于这些原因，我们将引入在java.lang.instrument包中定义的java转换代理（在j2se 5.0及更高版本中才可用）。其实，一个转换代理就是一个对象，它实现了定义一个唯一的transform()方法的java.lang.instrument.classfiletransformer接口。当一个转换实例被注册到jvm时，对于每一个在jvm中创建的类都将调用该转换器实例。在jvm加载这个类之前，该转换器能够存取类的字节码并能够修改该类的描述。

　　转换代理能够被使用命令行参数（形式为"-javaagent:jarpath[=options]"）注册到jvm。其中，jarpath是指向包含该代理类的jar文件的路径，而options是该代理的一个参数串。这个代理jar文件使用一个特定的manifest属性来指定实际的代理类，这要求必须定义一个方法"public static void premain(string options，instrumentation inst)"。这个代理premain()方法是在应用程序的main()方法执行之前被调用的，而且它能够使用传入的java.lang.instrument.instrumentation类实例注册一个实际的转换器。

　　在我们的例子中，我们定义一个代码-它实现字节码操作以透明地把运行时刻调用添加到我们的ioc容器（service locator插件）。该代理将通过核实存在于类中的serviceable注解来识别可服务的对象。然后，它修改所有可用的构造器-把回调添加到ioc容器-以便它能够在实例化时刻配置和初始化该对象。

　　让我们假定这个对象依赖于外部服务：

@serviceable public class serviceableobject { 　public serviceableobject() { 　　system.out.println("initializing..."); 　} 　@injected public void aservicingmethod( 　　service s1， 　　anotherservice s2) { 　　　// ...省略... 　　} 　}

　　在代理修改完之后，它的字节码将会与通过正常编译这个类得到的字节码一致：

@serviceable public class serviceableobject { 　public serviceableobject() { 　　servicelocator.service(this); 　　system.out.println("initializing..."); 　} 　@injected public void aservicingmethod( 　　service s1， 　　anotherservice s2) { 　　　// ... 省略... 　　} }

　　使用这种方案，现在我们能够正确地配置可服务的对象并且使之用于应用程序中而不需要开发者"硬性地绑定"对于容器的依赖性。开发者将只需要使用可服务的注解来标志可服务的对象即可。代理代码如下所示：

public class ioctransformer implements classfiletransformer { 　public byte[] transform(classloader loader，string classname，class＜?＞ classbeingredefined， protectiondomain protectiondomain，byte[] classfilebuffer) 　　throws illegalclassformatexception { 　　　system.out.println("loading " + classname); 　　　classreader creader = new classreader(classfilebuffer); 　　　//分析类文件 　　　constructorvisitor cv = new constructorvisitor(); 　　　classannotationvisitor cav = new classannotationvisitor(cv); 　　　creader.accept(cav， true); 　　　if (cv.getconstructors().size() ＞ 0) { 　　　　system.out.println("enhancing "+classname); 　　　　//生成增强的构造器类 　　　　classwriter cw = new classwriter(false); 　　　　classconstructorwriter writer = new classconstructorwriter(cv.getconstructors()，cw); 　　　　creader.accept(writer， false); 　　　　return cw.tobytearray(); 　　　} 　　　else 　　　　return null; 　　} 　　public static void premain(string agentargs， instrumentation inst) { 　　　inst.addtransformer(new ioctransformer()); 　　} 　}

　　上面代码中，类constructorvisitor，classannotationvisitor，classwriter和classconstructorwriter负责使用objectweb asm库进行字节码操作。

　　asm使用访问者模式来把类数据（包括指令序列）处理为事件流。在解码一个现有类时，asm为我们生成事件流，并调用我们的方法来处理事件。当生成一个新类时，相反的事情发生了：我们生成了一个事件流-由asm库负责把它转换成一个生成的类。注意，这种方法并不依赖于使用的特定的字节码库（在我们的例子中，使用的是asm）；其它一些可用的方案，例如bcel或javassist，也可以良好地实现这一工作。

　　在此，我们不会详细涉及asm的内部机理。在本文中，仅了解constructorvisitor和classannotationvisitor对象用于标识标有可服务的注解的类并且负责收集它们的构造器已经足够了。它们的源码如下所示：

public class classannotationvisitor extends classadapter { 　private boolean matches = false; 　public classannotationvisitor(classvisitor cv) { 　　super(cv); 　} 　@override 　public annotationvisitor visitannotation(string desc， boolean visible) { 　　if (visible &&desc.equals("lcom/onjava/servicelocator/annot/serviceable;")) { 　　　matches = true; 　　} 　　return super.visitannotation(desc， visible); 　} 　@override 　public methodvisitor visitmethod( 　　int access， 　　string name， 　　string desc， 　　string signature， 　　string[] exceptions) { 　　　if (matches) 　　　　return super.visitmethod(access，name，desc，signature，exceptions); 　　　else { 　　　　return null; 　　} 　} } public class constructorvisitor extends emptyvisitor { 　private set＜method＞ constructors; 　public constructorvisitor() { 　　constructors = new hashset＜method＞(); 　} 　public set＜method＞ getconstructors() { 　　return constructors; 　} 　@override 　public methodvisitor visitmethod( 　　int access， 　　string name， 　　string desc， 　　string signature， 　　string[] exceptions) { 　　　type t = type.getreturntype(desc); 　　　if (name.indexof("＜init＞") != -1 && t.equals(type.void_type)) { 　　　　constructors.add(new method(name，desc)); 　　　} 　　　return super.visitmethod(access，name，desc，signature，exceptions); 　　} 　}

　　对于前面的类所收集到的每一个构造器，由一个classconstructorwriter的实例来修改它-通过下面的调用注入到插件service locator中：

com.onjava.servicelocator.servicelocator.service(this);

　　完成这一工作的asm方法可以通过下列指令来实现：

//mv是一个asm方法访问者，这是一个允许方法操作的类 mv.visitvarinsn(aload， 0); mv.visitmethodinsn( invokestatic， "com/onjava/servicelocator/servicelocator"， "service"， "(ljava/lang/object;)v");

　　第一条指令把对this对象的参考加载到将在第二条指令使用的栈上，这里调用了servicelocator类的一个静态方法。

五. eclipse rcp应用程序举例

　　现在，我们已经为构建示例应用程序作好了准备。

　　我们的示例应用程序用于实现向用户展示其感兴趣的警句和引用语-例如fortune cookies。它由下面四个插件组成：

　　? service locator插件，它实现ioc框架

　　? fortuneservice插件，它实现管理fortune cookies的服务

　　? fortuneinterface插件，它"发行"存取服务的公共接口

　　? 这个fortuneclient插件，它实现eclipse应用程序并且在eclipse视图中显示格式化的警句

　　我们采用的ioc设计使服务实现独立于客户端；现在，该服务实现可以被修改了，而同时不影响客户端。图2展示了插件之间的依赖性。

图2.插件之间的依赖性：servicelocator和接口定义使服务与客户端分离开来。

　　正如在前一节中所描述的，service locator将把客户端和该服务绑定到一起以便向用户显示警句。这个fortuneinterface只定义了公共接口ifortunecookie，客户端用它来存储cookie消息：

public interface ifortunecookie { 　public string getmessage(); }

　　这个fortuneservice插件提供了一个简单的服务工厂-由它负责创建ifortunecookie的实现：

public class fortuneservicefactory implements iservicefactory { 　public object getserviceinstance() 　throws serviceexception { 　　return new fortunecookieimpl(); 　} 　// ...省略... }

　　这个工厂被注册到service locator插件作为一种eclipse扩展，如其plugin.xml描述符文件所展示的：

＜?xml version="1.0" encoding="utf-8"?＞ ＜?eclipse version="3.0"?＞ ＜plugin＞ ＜extension point="com.onjava.servicelocator.servicefactory"＞ ＜servicefactory class="com.onjava.fortuneservice.fortuneservicefactory" id="com.onjava.fortuneservice.fortuneservicefactory" name="fortune service factory" resourceclass="com.onjava.fortuneservice.ifortunecookie"/＞ ＜/extension＞ ＜/plugin＞

　　在此，resourceclass属性定义由这个工厂提供的服务的类。这个被描述的服务为定义在fortuneclient插件中的eclipse视图所用：

@serviceable public class view extends viewpart { 　public static final string id = "fortuneclient.view"; 　private ifortunecookie cookie; 　@injected(optional=false) 　public void setdate(ifortunecookie cookie) { 　　this.cookie = cookie; 　} 　public void createpartcontrol(composite parent){ 　　label l = new label(parent，swt.wrap); 　　l.settext("your fortune cookie is:/n" + cookie.getmessage()); 　} 　public void setfocus() {} }

　　请注意，这里使用了serviceable和injected注解来定义对于外部服务的依赖性。最终结果是，createpartcontrol()能够自由地使用cookie对象-在它已经被成功地初始化的保证下。这个示例应用程序显示于图3中。

图3.这个示例应用程序中具有一个从服务插件中检索到的fortune cookie

　　六. 结论

　　在本文中，我讨论了如何利用一种强有力的编程模式-它使用一种正在出现的加速java客户端应用程序开发的技术（eclipse rcp）来简化代码依赖性(控制反转)处理。尽管我没有实现其中的许多细节，但是我展示了一个示例应用程序-其中，服务与服务客户端能够分离开来。我还向你展示了，当同时开发客户端和服务时eclipse插件技术是如何保持关系分离的。然而，还有大量的有趣的内容值得探讨，例如当不再使用服务时的清除策略，或者使用模拟服务对我们的客户端插件进行单元测试的方式，等等。所有这些，只好请读者来完成了。