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