再次小结领域模型的种种观点

^_^，再仔细想了一下，决定利用这几天空闲的时间作出一个beta的RuleEngine来，现在有点兴奋，感觉这是一个非常的思路，前期的工作可能大一些，但是对于需要灵活定制、修改策略的需求来说，这样的一个基于Script的Rule Engine还是很有必要的，各位，可否告诉我已经有人做了这样类似的咚咚，如果没有人，^_^，我要开始干活了，把它放到SF上去。

可能大家对于CO的定位还不是很明确，无法区分CO和一般设计的区别，我们就举一个形象一点的例子来解说一下。

还是以现实世界为分析对象，上帝的设计无疑最具说服力。
上文从原子层面来进行分析，从而推导出完美原子类型的可行性。世界中的一切，但凡物质（仅限于人类可以感知的范围），毫无例外都是由元素周期表中已列出或未列出的百多个原子构成，所以只要知道物质的原子构成，根据原子特性就可以推断出其特性，反过来也一样，如果想要获得某种特性的物质，就必须组合特定原子。

那么，既然现实世界中的一切物质皆由原子组合而成，那么是不是意味着CO也是同一个道理，在OO系统里面定义几个有限的原子类型，只要将它们简单组合在一起就可以运作？其实不然。

上帝的设计实际上也是分两种：低阶静态设计、高阶动态设计，高阶动态设计是建立在低阶静态设计的基础之上。
对于自然物质来说，区分这两种设计的方法也很简单：由原子所组成的物质是否具备生命特性。
对于无生命物质来说，物质之间所发生的反应由其原子构成决定，但是对于生物而言，根据其原子构成去推测生物之间的反应情况是不可想象的。当然，一头死狼和一只死兔子放在一起，还是根据原子特性发生反应的。现在来研究一下一头活狼和一头活兔子放在一起的情形，饥饿的狼会扑上去捕食兔子，吃饱喝足的狼大概会冲上去吓唬一下兔子，无论结果如何，生物的行为特性已经不可能根据其原子构成推导出来。这时候我们不禁要问，规则是如何被改变的？

生物学研究至少揭示了部分答案：DNA 或 RNA，我们没有办法了解这种双螺旋的分子结构具体到底是如何运作的，但至少了解到这样一个事实：经过反复筛选淘汰的生物结构设计以某种规则描述的形式保存下来，并且不断复用、改良。再回过头来看OO设计，我们总是热衷于去捕捉易于观察、认识的表象：动物，肉食动物，植食动物，这种以单纯的分类法为主导的所谓“面向对象”方式得到的是静态设计，然而这种设计所取得的效果与上帝的设计截然相反，上帝的静态类型设计简洁而完美，是一切高阶设计的基石、起源。人们之所以在静态类型设计上屡遭挫折，关键还是在于人类首先能够观察到的只能是物质系统运行的结果，换句话说就是所谓的“表象”，另外一点则是从功利主义出发，只要能满足眼前需求的设计就是好的设计，至于背后的内里乾坤则可以搁置一边。

CO的提出，主要目的也是要摆脱以分类法为主导的静态设计，转向更高阶的面向规则或机制的动态设计。只是CO名字取得不好，事实上object和component到底有什么实质区别也什么人能说的清，component这个概念出现也不是一天两天的事了，而且也根本体现不出高阶动态设计的概念。况且高阶动态设计也不仅仅只有ajoo鼓吹的CO一种，所以大家看了CO之后才会有云里雾里的感觉。

真磨唧 。 

这句是真言，


窃以为：这个才是有可能解决静态类型OO根本问题的东西，庄的那个DJ的类型定义好像就是这么搞得，不过不是摆脱分类法，是摆脱静态分类。

你这种机械组合，盲目烂比论，才是需要打击对象呢。
首先，原子组合成分子，你就无法用组合的观点来看待分子的性质。
另外，谈到有无生命，你就更不着边，生命本质是啥？难道你看到的不是“表象”？
你咋知道上帝是通过组合的方式来设计世界呢？莫非。。。。。。
我认为上帝是凭直觉来设计的，不行么？

是有些别扭。不过，这个组合子的思想还是有借鉴意义的。

看不到解耦的需要吗？你就是说，连定义一个可以重用的or, ifelse的需求也没有？每次需要都重头再写一遍？or(or(a,b), ifelse(c,d,e))的需求不可能存在？这看上去不是什么了不起的算法呀，就是普通的业务逻辑表示。

你实说Rule的运算结果的类型么？

在haskell这种高级的泛型语言里面，这个类型不是问题。在ruby这种动态语言里面，也一样不是问题。

在java里面，只好用Object了。没办法。

为何不用ruby？自己做个语言，比较难让人接受。

所以说“everything is object”嘛，建议还是用OO来写，毕竟现在OO是主流，一个OO设计全世界通用，增加对Ruby或haskell的依赖只会限制应用范围。

drools之类的不是就做这个活的么？