忘记Scala,Qi4J是下一个 Java?

09-09-20 banq
                   

这段时间,围绕Evans DDD的DSL实现是一个大热门,有的从语言角度重新定义,比如Scala vs. Clojure

虽然Scala很象Java,但是语法比Java要复杂多,My experience with Scala (so far)认为,Scala功能要比Java强大,但是学习曲线不低。

Bruce Eckel这位编写"Java编程思想"一举成名的所谓大师,写了一篇Java: Evolutionary Dead End,认为Java是进化的死胡同,其实我个人对其书籍本身就有些反感,他并没有在书中写出Java的真正编程思想,是C语言思想的借尸还魂罢了,所以他的思维是有缺陷的,所以他写些大而化之的文章只是糊弄一下初学者罢了。

我一直认为,Java其实是很好理解易懂的语言,那么多人熟悉Java,而C#不过是第二个Java,这么多人学会一种语言,难道它就不是世界语吗?就象英语因为讲得人多了,所以就成世界语,成为大家交流工具了,语言不过是交流工具,在语言和MF提倡的领域模型的“语法”之间不一定要划等号。

所以,基于Java的框架也实现解决DSL和面向语言编程模型的问题,果然,针对这位大师的忽悠,基于Java的原汁原味的Qi4J框架横空出世了,Qi4J the next Java? Forget Scala

Qi4j有下面几个特点:

1.Behavior depends on Context 依赖场景的行为

2.Decoupling is a virtue 解耦融入血液。

3.Business Rules matters more.业务规则更重要

4.Classes are dead, long live interfaces.类已经死亡,接口万岁。

依赖场景的行为

对象的生命周期相对简单的领域模型已经OO要比我们想象得复杂多,例如:

1.一个鸡蛋变成鸡,从而成为食物。

2.我是在工作的程序员,一个父亲+丈夫在家里,一宗交通意外,猎人在丛林中的受害者祈祷。

不仅如此,对象在不同时期的组合composition 变化更大,我们要持续不断面对变化,这些变化往往来自于业务领域,OOP把这些变化容易搞大,大得经常销毁大块模型甚至返工。小题大做的意思?

类的属性经常会增加变化,如果属性拓展变化得已经面目全非,不是原来的类了,那么我们是不是要给这个类改名呢?不改名,因为不是原来的类,改了,就导致很多依赖它的其他类变化太大,导致这个模块的模型都要返工重新设计。

Qi4j认为当前所谓OOP其实一点不是OOP,实际是面向类编程,不是真正面向对象编程,类是第一等公民,对象是从类中衍生出来的;而在Qi4j宣称的面向组合编程Composite Oriented Programming模式中,对象才是真正第一等公民,对象创建一个或多个类。很有魄力的见解。

解耦融入血液

在OOP以类为第一公民的世界中,类之间引用造成了耦合,紧耦合是重用的死敌,而Qi4j的面向组合编程模式最大目标就是重用,所以,传统的OOP并不能真正实现重用,虽然我们有各种消除依赖的模式。Qi4j采取的是将类在细分,划分为更细的碎片,分为下面几个部分:

1.Mixins: 代表状态 如Name, Person, Adress 值对象的意思?

2.Concerns: 无态功能,如事务安全e.g. TransactionWrapper, Security AOP的细化

3.Constraints: 约束,参数检查等Checking parameters, e.g. NotNullConstraint

4.SideEffects:专门管理边界影响 Managing side effects, e.g. sending Mail

下面是一个基于Qi4j框架的接口:

@Concerns({Security.class, Transaction.class})
@SideEffect({MailNotification.class})
public interface PersonComposite
    extends Person, Name, Adress, Composite
{
}
<p>

Business Rules matters more

很多聪明的程序员总是认为架构中底层的框架比简单的领域模型更加重要,比如OSGI可能就是一个比较底层的框架,很多人热捧它,但是它如果脱离简化领域模型就没有意义,

领域模型是反映需求业务,是能够收到客户的钞票的,底层设施只是为这种目的实现的工具,别本末倒置了。如果我们更多程序员关注业务逻辑和领域模型,而不是关心事务 安全或框架的特点,软件生产力将得到真正加强。

Evans DDD一书写得很好,但是真正实现起来比较困难,因为缺乏一个语法环境,而Qi4j正是提供这样一个语法环境,什么时候DDD起飞了,也是Qi4j起飞之日。If DDD takes off, Qi4J or frameworks like Qi4J will take off too.

顺便罗嗦一句,本人当初推出开源Jdon框架其实也是为这个目标努力奋斗,只是徒有想法和构思,仍在不断发展中,和Qi4J相比还是有相当距离,不过看到距离就有努力方向了。

Qi4j项目

[该贴被admin于2010-03-15 15:56修改过]

                   

3
xmuzyu
2009-09-20 13:27

>>在Qi4j宣称的面向组合编程Composite Oriented Programming模式中,对象才是真正第一等公民,对象创建一个或多个类。很有魄力的见解。

面向组合编程很不错。DDD中的聚合,实体,值对象,约束,边界划分如果能在语言级别得到支持,那样就更爽了。

>>领域模型是反映需求业务,是能够收到客户的钞票的,底层设施只是为这种目的实现的工具,别本末倒置了。如果我们更多程序员关注业务逻辑和领域模型,而不是关心事务 安全或框架的特点,软件生产力将得到真正加强。

Evans DDD一书写得很好,但是真正实现起来比较困难,因为缺乏一个语法环境,而Qi4j正是提供这样一个语法环境,什么时候DDD起飞了,也是Qi4j起飞之日。If DDD takes off, Qi4J or frameworks like Qi4J will take off too.

呵呵,jdon的大力宣传使得更多的国人关注DDD,从我这次买书看出来了,现在想买本中译本的“领域驱动设计”比登天还难呵呵。帖子:

求购领域驱动设计一书

[该贴被admin于2009-09-20 13:42修改过]

bloodrate
2009-09-21 13:34

对于类似技术,我更多感兴趣的东西往往集中在

其是不是有大型成功案例

是否可生产化

IDE,插件,工具支持受否完备

应用服务器是否支持

等等问题,而不再是思想有多好,多么简化开发的理论

banq
2009-09-22 07:07

>类已经死亡,接口万岁

Qi4j不只是一个框架,其实为我们指出现实中OO的误区。

我曾经重构一个大型的BOSS,该BOSS使用Hibernate,屏蔽了数据库影响,基本都是使用面向对象设计,但是由于大量使用继承,导致耦合粒度太粗,结构混乱,这是OO之错?还是误用OO之错呢?

所以,在现实中,特别是领域建模时,使用继承会非常容易,可以说是直觉,但是使用接口才是设计,接口粒度要更细,至少有将行为和抽象分离的用处。

如果框架提供这种行为和抽象的分离约束就非常好,但是又会导致贫血模型,所以,现实中设计就是在博弈:最大限度用接口,然后将接口嵌入模型中(这个模型就是Qi4j所说的组合模型了,因为它是拆了组合得出来的,就象1+1=2的组合结果2一样)。

[该贴被banq于2009-09-22 07:08修改过]

colingo
2009-09-22 07:08

为了生计之余,偶觉得兴趣也是关键.: D

Qi4j思想不错。真正应用可能还需要些时日。

[该贴被xinying_ge于2009-09-22 07:10修改过]

4Go 1 2 3 4 下一页