开元框架HiveMind 下一代软件流行框架--邵京国

今天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的容器。