忘記Scala，Qi4J是下一個 Java?

banq發表於2009-09-20
Java
這段時間，圍繞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 class="indent">


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修改過]

相關文章