今天HiveMind 1.0 的final版本出来了, 看了看他的examples代码。 有了IoC(DI)的感觉之后再看这些代码, 越看感觉越清晰。 实现一个IoC的容器本身没什么可说的, 现在就以他自带的example为例,来看看HiveMind在这方面的实现方法。

example程序是一个四则运算的类,基本思想是将加减乘除都做成接口,用不同的方式实现;计算器(Caculator)继承了加减乘除接口,在运行过程中,具体的加减乘除操作类通过HiveMind的配置注入到CaculatorImpl中,当然CaculatorImpl也是通过Caculator接口通过工厂产生出来的,以下是他的具体代码:

 double arg0 = Double.parseDouble(args[0]);
        double arg1 = Double.parseDouble(args[1]);

        Registry registry = ExampleUtils.buildRegistry("examples.xml");

        // Since we know there's exactly *one* service-point implementing Calculator,
        // we can get it this way, and never have to know its service id.

        Calculator calculator = (Calculator) registry.getService(Calculator.class);

        System.out.println("Inputs:   " + arg0 + " and " + arg1);
        System.out.println("Add:      " + calculator.add(arg0, arg1));
        System.out.println("Subtract: " + calculator.subtract(arg0, arg1));
        System.out.println("Multiply: " + calculator.multiply(arg0, arg1));
        System.out.println("Divide:   " + calculator.divide(arg0, arg1));
       
        registry.shutdown();

嗯,Registry registry = ExampleUtils.buildRegistry("examples.xml");  这条语句看来是从examples.xml中进行相应的初始化并建立对应关系了,内部大概是根据配置文件定义拦截器,工厂,初始化方法之类,不用看。这里的Registry应该等于Spring中的ApplicationContext, Pico中的Configuration了。看了IoC容器这方面的也没什么别的东西,一定得有一个全局的东西hold这些被管理的类的。

下面的registry.getService(Calculator.class);看起来要比Spring的appContext.getBean(beanId)方便一点,在整个配置文件保证借口唯一的前提下,可以直接采用class作为参数取出对象。当然Spring完全可以这么做,只看Johnson先生高兴不高兴了。

Caculator接口继承了增删改查接口(就是4个各包含一个方法的接口)。

再看看examples.xml配置:

<module id="examples" version="1.0.0">
    <service-point id="Adder" interface="org.apache.hivemind.examples.Adder">
        <create-instance class="org.apache.hivemind.examples.impl.AdderImpl"/>
        <interceptor service-id="hivemind.LoggingInterceptor"/>
    </service-point>
    ...其他操作省略
    <service-point id="Calculator" interface="org.apache.hivemind.examples.Calculator">
        <invoke-factory>
            <!-- Most properties are autowired by the BuilderFactory -->
            <construct class="org.apache.hivemind.examples.impl.CalculatorImpl"/>
        </invoke-factory>
        <interceptor service-id="hivemind.LoggingInterceptor"/>
    </service-point>
</module>

仔细看看这个配置文件就可以看出一些有趣的东西:
service-point毫无疑问等于Spring中的bean。(Howard同志一向以长的配置名称闻名,这一点可以在Tapestry的配置文件中得到证实,不过比起Spring的超长package name和constant name,似乎又差了一点,呵呵),id, interface……等等,看来hlship完全不鼓励在这个Container中使用具体的类了,看看DTD文件的定义:

<service-point id=".." interface=".."
   [parameters-schema-id=".."]
   [parameters-occurs="unbounded |
             0..1 | 1 | 1..n | none"]>
 [parameters-schema]
 [create-instance]
 [invoke-factory]
 [interceptor]
</service-point>

确实没有class这个属性……这样做好还是不好?……不知道,完全面向接口的系统存在吗……这个问题暂时不想,以后再说。四个加减乘除的类的生成没什么好说的,看看
<service-point id="Adder" interface="org.apache.hivemind.examples.Adder">
     <create-instance class="org.apache.hivemind.examples.impl.AdderImpl"/>
     <interceptor service-id="hivemind.LoggingInterceptor"/>
</service-point>
的意思,应该是创建一个以org.apache.hivemind.examples.impl.AdderImpl的实例,从<create-instance>的DTD看来,他允许创建为primitive, singleton, threaded, pooled的形式。默认应该是每次调用创建一个实例吧,我猜。然后用一个拦截器(LogginInterceptor)来处理。

这里又发现了一个比Spring要方便的地方,interceptor可以直接定义在(我都不知道怎么说了,用Bean还是service-point?)Component的内部,用Spring的话还得另外建立一个新的Bean,然后指定Advice的作用域,如果系统中只有一两处需要的话,多一个Bean的配置显得有点不雅。记得xWork也是这样定义interceptor的。

下面的按照工厂形式创建实例有点意思。

    <service-point id="Calculator" interface="org.apache.hivemind.examples.Calculator">
        <invoke-factory>
            <!-- Most properties are autowired by the BuilderFactory -->
            <construct class="org.apache.hivemind.examples.impl.CalculatorImpl"/>
        </invoke-factory>
        <interceptor service-id="hivemind.LoggingInterceptor"/>
    </service-point>

先看看CaculatorImpl的实现:
public class CalculatorImpl implements Calculator {
    private Adder _adder;
    private Subtracter _subtracter;
    private Multiplier _multiplier;
    private Divider _divider;

    public double add(double arg0, double arg1) {
        return _adder.add(arg0, arg1);
    }

    ...后面的减乘除就不写了,类似

    ...一堆的setter/getter就不写了
}


刚开始诧异了一下,在我感觉里,这里怎么说应该有个输入参数的地方,就象下面:

   <invoke-factory>
        <construct class="org.apache.hivemind.examples.impl.CalculatorImpl">
 <set-property name="adder" ref="Adder" />
 ...
 </construct>
   </invoke-factory>

看看他的注释:Most properties are autowired by the BuilderFactory,看样子他在BuilderFactory中默认将同id的service-point注入到construct中去了,这种便利是否必要?毕竟遍历一个类的set方法,判断方法所需的类型,寻找registry中的service-point然后注入,这都是需要代价的……没想清楚,暂时放下。

题外话:我没有一直跟随HiveMind的版本变化,但在我的记忆中,1.0的某个rc版本将配置文件换成了Howard同志自己发明的Simple Data Language,其实就是hlship根据JavaCC自己组织了一套语法,然后将所有的配置文件用这种语法改写……没多少日子这个东西就被pass掉了。直到现在我还怀疑他做这件事情的动机,目前最能让我觉得有趣的一种解释是:Howard看到JavaCC很强大,能够很轻易的定义一种新的语法并解析,具备Tapestry全新的创意的Howard,一时头脑发热就加入了这个东东……呵呵

HiveMind还有一些其他的特性,比如系统所有配置的文档生成(这个功能Spring加上就好了)以及其他的一些方便的特性。Howard一再强调HiveMind是一个Micro Kernel的框架,但在我看来,他是一个新的,可能更加方便的,完全面向接口的,基于IoC的容器。

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐