奇技淫巧？

ruby没了拐棍到是真的。鱼与熊掌很多情况下不能兼得的。

技巧很好，但是有点过了，在团队开发中这种方式应是不受欢迎的。

我想不是为了编程而编程，也不是为了展示技巧而编程，以清晰、高效的方式实现编写出强壮的代码，满足需求是最重要的。

需要自己去用心和关注的事情很多，完全没有必要浪费时间于这种让自己自觉是高手的技巧中。

呵呵，一看开头就是酒窝

真有意思!呵呵

预加之罪，何患无词

感觉 lz好痛苦

思路新颖，快刀斩乱麻！

看了文章感觉很有意思，作者的思维挺好玩，感觉如果平时应用开发还是不要这样的好，如果是写一些特殊的需求，例如框架什么的还是不错的。另外再提供一个思路：

ScriptEngineManager factory = new ScriptEngineManager();
ScriptEngine engine = factory.getEngineByName("JavaScript");
for(int i=0;i<arr.length;i++){
    engine.put("obj", arr[i]);
    Object obj = engine.eval("obj."+method);
    if (obj instanceof Double){
        sum += ((Double)obj).doubleValue();
    ｝
}

是用jdk1.6中的script就可以简单实现了，好处是写起来方便，学习成本低。坏处是也存在重构问题，并且内部实现和动态代理、反射等也差不哪里去。

呵呵 我觉得楼主在最后一贴的“疯狂”是有道理的，当整个系统中大部分业务处理逻辑都是“求和”的情况下，用一种方式将这种逻辑抽象出来我认为也不为过，只不过他用的技巧有点让人眼晕，不过没关系，因为一个团队里总会出一两个这样的“疯子”，让这些“疯子”维护这种代码即可，从架构的角度上看，楼主明显已经抽象出一层业务处理逻辑（hoops...难不成这就是传说中的业务平台。。。）
从design的方向上，我赞成楼主的观点，但从design的技巧上我不认同楼主的技巧，why：因为楼主利用了原有设计上的一个缺陷，就是对每一个class原来的设计都强迫其实现一个接口，这种取巧的方式不利于以后architecture的重构，而且楼主为了让没有实现接口的class也能用到重构后的模块，又新加了一些特定的接口，而这些接口是没有任何业务语义的，仅仅是为了用到重构后的模块而加的（hoops...难不成这就是传说中的侵入。。。）好吧，如果你想让按楼主重构后的架构clean一些的话（我承认我有一些技术洁癖），又需要再付出努力组织这些东东，而这样的代价是否值得呢，这实际上就是在重新架构你的system。。。

理解万岁。呵呵。

不过，这些新的接口是不要求被sum的类来"implements"的。因为“酒窝”可以搞定这一切。所以，不能算“侵入”吧？