在Eclipse RCP中实现反转控制(IoC)

翻译 2006年06月12日 19:24:00

在Eclipse RCP中实现反转控制(IoC)

作者 Riccardo Govoni  2006年6月7日
翻译 土豆爸爸 2006年6月12日
原文 在这里

Eclipse富客户平台(RCP)是一个功能强大的软件平台,它基于插件间的互连与协作,允许开发人员构建通用的应用程序。RCP使开发人员可以集中精力进行应用程序业务代码的开发,而不需要花费时间重新发明轮子编写应用程序管理的逻辑。

反转控制(Inversion of Control, IoC)和依赖注入(Dependency Injection, DI)是两种编程模式,可用于减少程序间的耦合。它们遵循一个简单的原则:你不要创建你的对象;你描述它们应当如何被创建。你不要实例化你的部件所需要对象或直接定位你的部件所需要的服务;相反,你描述哪个部件需要哪些服务,其它人(通常是一个容器)负责将它们连接到一起。这也被认为是好莱坞法则:don't call us--we'll call you。

本文将描述一个简单的方式在Eclipse RCP应用程序中使用依赖注入。为了避免污染Eclipse 平台的基础结构以及透明地在RCP之上添加IoC框架,我们将结合使用运行时字节码操作技术(使用 ObjectWeb ASM库)、Java类加载代理(使用java.lang.instrument包)以及Java annotation。

什么是Eclipse富客户平台?

用一句话来讲,富客户平台是一个类库、软件框架的集合,它是一个用于构建单机和连网应用程序的运行时环境。

尽管Eclipse被认为是构建集成开发环境(IDE)的框架,从3.0开始,Eclipse整个产品进行了重构,分割成各种不同的部件,它些部件可以用于构建任意的应用程序。其中的一个子集构成了富客户平台,它包含以下元素:基本的运行时环境、用户界面组件(SWT和JFace)、插件以及 OSGI层。图1显示了Eclipse平台的主要部件。

Eclipse平台的主要部件
图1. Eclipse平台的主要部件

整个Eclipse平台是基于插件和扩展点。一个插件是一个可以独立开发和发布的最小的功能单元。它通常打包成一个jar文件,通过添加功能(例如,一个编辑器、一个工具栏按钮、或一个编译器)来扩展平台。整个平台是一个相互连接和通信的插件的集合。一个扩展点是一个互相连接的端点,其它插件可以用它提供额外的功能(在Eclipse中称为扩展)。扩展和扩展点定义在XML配置文件中,XML文件与插件捆绑在一起。

插件模式加强了关注分离的概念,插件间的强连接和通讯需要通过配线进行设置它们之间的依赖。典型的例子源自需要定位应用程序所需要的单子服务,例如数据库连接池、日志处理或用户保存的首选项。反转控制和依赖注入是消除这种依赖的可行解决方案。

反转控制和依赖注入

反转控制是一种编程模式,它关注服务(或应用程序部件)是如何定义的以及他们应该如何定位他们依赖的其它服务。通常,通过一个容器或定位框架来获得定义和定位的分离,容器或定位框架负责:

  • 保存可用服务的集合
  • 提供一种方式将各种部件与它们依赖的服务绑定在一起
  • 为应用程序代码提供一种方式来请求已配置的对象(例如,一个所有依赖都满足的对象), 这种方式可以确保该对象需要的所有相关的服务都可用。

现有的框架实际上使用以下三种基本技术的框架执行服务和部件间的绑定:

  • 类型1 (基于接口): 可服务的对象需要实现一个专门的接口,该接口提供了一个对象,可以从用这个对象查找依赖(其它服务)。早期的容器Excalibur使用这种模式。
  • 类型2 (基于setter): 通过JavaBean的属性(setter方法)为可服务对象指定服务。HiveMindSpring采用这种方式。
  • 类型3 (基于构造函数): 通过构造函数的参数为可服务对象指定服务。PicoContainer只使用这种方式。HiveMind和Spring也使用这种方式。

我们将采用第二种方式的一个变种,通过标记方式来提供服务(下面示例程序的源代码可以在资源部分得到)。 声明一个依赖可以表示为:


@Injected public void aServicingMethod(Service s1, AnotherService s2) {
  // 将s1和s2保存到类变量,需要时可以使用
}

反转控制容器将查找Injected注释,使用请求的参数调用该方法。我们想将IoC引入Eclipse平台,服务和可服务对象将打包放入Eclipse插件中。插件定义一个扩展点 (名称为com.onjava.servicelocator.servicefactory),它可以向程序提供服务工厂。当可服务对象需要配置时,插件向一个工厂请求一个服务实例。ServiceLocator类将完成所有的工作,下面的代码描述该类(我们省略了分析扩展点的部分,因为它比较直观):


   /**
     * Injects the requested dependencies into the parameter object. It scans
     * the serviceable object looking for methods tagged with the
     * {@link Injected} annotation.Parameter types are extracted from the
     * matching method. An instance of each type is created from the registered
     * factories (see {@link IServiceFactory}). When instances for all the
     * parameter types have been created the method is invoked and the next one
     * is examined.
     * 
     * @param serviceable
     *            the object to be serviced
     * @throws ServiceException
     */
    public static void service(Object serviceable) throws ServiceException {
        ServiceLocator sl = getInstance();
        if (sl.isAlreadyServiced(serviceable)) {
            // prevent multiple initializations due to
            // constructor hierarchies
            System.out.println("Object " + serviceable
                    + " has already been configured ");
            return;
        }

        System.out.println("Configuring " + serviceable);

        // Parse the class for the requested services
        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<?> class : m.getParameterTypes()) {
                    IServiceFactory factory = sl.getFactory(class, ann
                            .optional());
                    if (factory == null) {
                        skip = true;
                        break;
                    }
                    Object service = factory.getServiceInstance();

                    // sanity check: verify that the returned
                    // service's class is the expected one
                    // from the method
                    assert (service.getClass().equals(class) || class
                            .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采用了复杂的类加载器和实例化策略(想一下createExecutableExtension()) 来维护插件的隔离和强制可见性限制。我们不希望修改或替换这些策略而引入我们的基于容器的实例化规则。
  • 显式地引用这样一个入口点(Service Locator插件中定义的service()方法) 将强迫应用程序采用一种显式地模式和逻辑来获取已初始化的部件。这表示应用程序代码出现了library lock-in。我们希望定义可以协作的插件,但不需要显示地引用它的基代码。

出于这些原因,我将引入java转换代理,它定义在 java.lang.instrument 包中,J2SE 5.0及更高版本支持。一个转换代理是一个实现了 java.lang.instrument.ClassFileTransformer接口的对象,该接口只定义了一个 transform()方法。当一个转换实例注册到JVM时,每当JVM创建一个类的对象时都会调用它。这个转换器可以访问类的字节码,在它被JVM加载之前可以修改类的表示形式。

可以使用JVM命令行参数注册转换代理,形式为-javaagent:jarpath[=options],其中jarpath是包含代码类的JAR文件的路径, options是代理的参数字符串。代理JAR文件使用一个特殊的manifest属性指定实际的代理类,该类必须定义一个 public static void premain(String options, Instrumentation inst)方法。代理的premain()方法将在应用程序的main()执行之前被调用,并且可以通过传入的java.lang.instrument.Instrumentation对象实例注册一个转换器。

在我们的例子中,我们定义一个代理执行字节码操作,透明地添加对Ioc容器(Service Locator 插件)的调用。代理根据是否出现Serviceable注释来标识可服务的对象。接着它将修改所有的构造函数,添加对IoC容器的回调,这样就可以在实例化时配置和初始化对象。

假设我们有一个对象依赖于外部服务(Injected注释):

@Serviceable
public class ServiceableObject {
  public ServiceableObject() {
    System.out.println("Initializing...");
  }

  @Injected public void aServicingMethod(Service s1, AnotherService s2) {
    // ... omissis ...
  }
}

当代理修改之后,它的字节码与下面的类正常编译的结果一样:

@Serviceable
public class ServiceableObject {
  public ServiceableObject() {
    ServiceLocator.service(this);
    System.out.println("Initializing...");
  }

  @Injected public void aServicingMethod(Service s1, AnotherService s2) {
    // ... omissis ...
  }
}

采用这种方式,我们就能够正确地配置可服务对象,并且不需要开发人员对依赖的容器进行硬编码。开发人员只需要用Serviceable注释标记可服务对象。代理的代码如下:


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

        // Parse the class file
        ConstructorVisitor cv = new ConstructorVisitor();
        ClassAnnotationVisitor cav = new ClassAnnotationVisitor(cv);

        creader.accept(cav, true);

        if (cv.getConstructors().size() > 0) {
            System.out.println("Enhancing " + className);
            // Generate the enhanced-constructor class
            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());
    }

}

ConstructorVisitorClassAnnotationVisitor ClassWriter以及ClassConstructorWriter使用ObjectWeb ASM库执行字节码操作。

ASM使用visitor模式以事件流的方式处理类数据(包括指令序列)。当解码一个已有的类时, ASM为我们生成一个事件流,调用我们的方法来处理这些事件。当生成一个新类时,过程相反:我们生成一个事件流,ASM库将其转换成一个类。注意,这里描述的方法不依赖于特定的字节码库(这里我们使用的是ASM);其它的解决方法,例如BCEL或Javassist也是这样工作的。

我们不再深入研究ASM的内部结构。知道ConstructorVisitorClassAnnotationVisitor对象用于查找标记为Serviceable类,并收集它们的构造函数已经足够了。他们的源代码如下:

        
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 is an ASM method visitor,
// a class which allows method manipulation
mv.visitVarInsn(ALOAD, 0);
mv.visitMethodInsn(
    INVOKESTATIC, 
    "com/onjava/servicelocator/ServiceLocator", 
    "service", 
    "(Ljava/lang/Object;)V");

第一个指令将this对象引用加载到栈,第二指令将使用它。它二个指令调用ServiceLocator的静态方法。

Eclipse RCP应用程序示例

现在我们具有了构建应用程序的所有元素。我们的例子可用于显示用户感兴趣的名言警句。它由四个插件组成:

  • Service Locator插件,提供IoC框架
  • FortuneService插件,提供服务管理fortune cookie
  • 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();
    }

    // ... omissis ...

}

工厂注册到service locator插件的扩展点,在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() {
    }
}

注意这里出现了ServiceableInjected注释,用于定义依赖的外部服务,并且没有引用任何服务代码。最终结果是,createPartControl() 可以自由地使用cookie对象,可以确保它被正确地初始化。示例程序如图3所示

示例程序
图3. 示例程序

结论

本文我讨论了如何结合使用一个强大的编程模式--它简化了代码依赖的处理(反转控制),与Java客户端程序(Eclipse RCP)。即使我没有处理影响这个问题的更多细节,我已经演示了一个简单的应用程序的服务和客户是如何解耦的。我还描述了当开发客户和服务时, Eclipse插件技术是如何实现关注分离的。然而,还有许多有趣的因素仍然需要去探究,例如,当服务不再需要时的清理策略,或使用mock-up服务对客户端插件进行单元测试,这些问题我将留给读者去思考。

参考

Riccardo Govoni has been working since 2003 as a J2EE developer for a financial services company in the northern part of Italy.

Spring框架中IoC(控制反转)的原理

一.IoC的基础知识以及原理: 1.IoC理论的背景:在采用面向对象方法设计的软件系统中,底层实现都是由N个对象组成的,所有的对象通过彼此的合作,最终实现系统的业务逻辑。即软件系统中对象之间的耦合,对...
  • u012561176
  • u012561176
  • 2015年05月26日 12:18
  • 11432

IoC(控制反转)的主要组件和注入的两种方式

一.IoC的主要组件: (1).Spring框架的两个最基本和最重要的包是org.springframework.beans.factory(该包中的主要接口是BeanFactory)和org.spr...
  • u012561176
  • u012561176
  • 2015年05月26日 13:26
  • 3190

JAVA菜鸟学习日记——简单代码实现IOC控制反转

原来校招时候的时候刷过一道题——写段代码实现控制反转,现在终于有了些思路~自己留念,同时分享给大家。...
  • Autobot_song
  • Autobot_song
  • 2016年12月22日 20:08
  • 973

深入理解IOC控制反转及应用实例

一、IOC雏形 1、程序V1.0 话说,多年以前UT公司提出一个需求,要提供一个系统,其中有个功能可以在新春佳节之际给公司员工发送一封邮件。邮件中给大家以新春祝福,并告知发放一定数额的...
  • lqw05
  • lqw05
  • 2016年08月14日 16:29
  • 1625

透彻理解IoC(控制反转)

 引述:IoC(控制反转:Inverse of Control)是Spring容器的内核,AOP、声明式事务等功能在此基础上开花结果。但是IoC这个重要的概念却比较晦涩隐讳,不容易让人望文生义,...
  • u014563989
  • u014563989
  • 2017年02月15日 09:26
  • 6315

SSH学习八 Spring框架 -- 控制反转实现Ioc

Spring的核心是控制反转(IoC)和面向切面(AOP)控制反转——Spring通过一种称作控制反转(IoC)的技术促进了低耦合。当应用了IoC,一个对象依赖的其它对象会通过被动的方式传递进来,而不...
  • u011026968
  • u011026968
  • 2015年07月31日 21:10
  • 739

Eclipse RCP开发桌面程序

KentySky 站在巨人的肩上,希望自己也可以长高一点!!! 博客园   首页   博问   闪存   新随笔   联系   订阅  管理 随笔-251  评论-86  文...
  • sinat_18366705
  • sinat_18366705
  • 2016年05月10日 12:02
  • 1831

什么是控制反转/依赖注入?

控制反转(IoC=Inversion of Control)IoC,用白话来讲,就是由容器控制程序之间的(依赖)关系,而非传统实现中,由程序代码直接操控。这也就是所谓“控制反转”的概念所在:(依赖)控...
  • makerule
  • makerule
  • 2015年11月25日 16:13
  • 968

eclipse_RCP添加视图

源文件:http://blog.csdn.net/lyq19870515/article/details/9346921 想要在RCP里添加视图 那就必须先建立视图: [j...
  • luoww1
  • luoww1
  • 2015年11月16日 14:54
  • 1209

eclipse rcp 打包出适合不同操作系统和操作位数.

1、查看自己eclipse的版本信息。点击菜单中的“Help”--->About Eclipse SDK,查看当前eclipse版本信息 2、在官网http://www.eclips...
  • luoww1
  • luoww1
  • 2013年03月15日 15:12
  • 1863
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:在Eclipse RCP中实现反转控制(IoC)
举报原因:
原因补充:

(最多只允许输入30个字)