長期以來，通過OOP對象集對領域概念進行建模的目標並未得到充分實現。那 麼迄今為止，我們萬般努力但難以解決的根本問題到底是什麼？有沒有更好的解 決辦法？在本文中我們將介紹面向組合編程（COP，Composite Oriented Programming）的概念，展示它如何規避OOP存在的一些問題，並重先點燃使用可 重用部件組裝領域建模的希望。
問題
我為何物？實際中我可以有多重身份。某些時候，我是編寫軟件的開發者；另 些時候，我是給大家講解某個有關Java話題的軟件開發者。但其他時候，我可能 有完全不同的身份，比如銀行的客戶、大學的校友。簡而言之，我不同時候的身 份，由當時的具體環境決定。在不同的環境中，我需要通過不同接口、以相應行 為與之交互。在所有這些環境中，我其實就是具有不同接口同一個對象。在我編 寫軟件的時候銀行不會出現另一個我。
解決方案
如果在軟件中用OOP為我建模，一些人會將我設計為一個Developer類。但這樣 一個類顯然不能在不同時候表達我的不同身份（比如一個大學校友，因為 Developer類不包括社交概念）。因此對我建模的結果，可能會是幾個不同的類， 或者在一個類中實現所有行為。在本文中，我們提出另一種方案：利用 Mixin（ 混入）概念完成這個實現。
組合
首先，Mixin被實現為一個普通Java類，它通常實現一個特定接口，而這個接 口將是Composite所要暴露接口的一部分。接著，我們用如下方法聲明一個 Composite：創建一個Java接口，用注解聲明它要用到的Mixin，並且使用 “extends”關鍵字指明需暴露哪些領域接口。通過這一方法，我們就可以載一個 集中的地點明確定義Composite的結構和行為。
使用COP時，雖然把橫切關注點保留在獨立的實現類中是一個不錯的主意，但 是它們的裝配或組成方式應該還是集中用Java接口來說明。為了避免出現重復的 說明，我們可以通過“extends”關鍵字重用被擴展接口中的聲明。這樣，如果修 改了被擴展接口，從其擴展而來的Composite接口聲明就會自動改變，不需我們逐 個做人工修改。
利用這種辦法，我們相信可以做到兩全其美：存在於各個單獨實現類中的關注 點實現了分離，每個類僅需關注特定的任務；對於Composite最終應該是什麼樣的 描述則是集中和確定的，這樣，Composite的開發者就可以全權負責定義中應該包 含的內容。
代碼示例
Composite在實際中如何具體應用呢？讓我們看一個例子。假設我是一個 Composite，那麼可如下描述我:
@Mixins({DeveloperMixin.class, SpeakerMixin.class, AlumniMixin.class})
public interface HumanComposite
extends Developer, Speaker, Alumni, Composite
{}
被擴展接口中包含了實際要被調用的方法，由Qi4j運行時環境去構造一個 Composite實例，這一實例可以將“來自客戶端的調用”路由給特定的 Mixin實例 。但從客戶端的角度看，這個Composite實例完全是一個普通Java對象（盡管與普 通OOP方法實現的領域對象比較起來，它有更多的接口）。像Developer 這樣的領 域接口是普通接口，和Qi4j無任何特殊關系，其實現本身也是實現了該接口的簡 單Java類。但是上面所說的領域對象的身份是由 Composite實例而非某個Mixin實 例定義的，這樣就解決了身份問題：對“我”這個對象的引用，可在系統范圍裡 傳遞，並被傳遞給在特定上下文環境中很有用的接口。如果引入更多領域或上下 文環境時，也可通過擴展這個Composite來處理。
如需想創建另一個也使用Alumni接口的Composite及其實現，我們可以讓此接 口也擴展Alumni，並聲明使用相同的Mixin。因此，多重繼承和復用基礎類的常見 問題也解決了。
LMM結構
軟件通常是在紙上分模塊、分層進行設計的。我們對類似如下的設計圖已經非 常熟悉了：
這個圖包含有多個模塊，不同模塊構成了不同層，而各層又疊放在一起。我們 可將這種設計方法簡稱為LMM（Layered Modules Metaphor，分層模塊表示法）。 LMM圖可用來傳達一個整體應用的總括，不讓我們陷入太多的細節當中。嚴格按照 LMM的要求設計系統，可減少系統缺陷、降低長期維護成本，這種系統對未來變更 的反映也可更為靈活。絕大多數項目都使用LMM來描述應用程序的構成方式，許多 項目設法遵循LMM，但只有很少的項目是按此執行的。我想我們都已經看到過很多 慘痛教訓，比如在基礎結構層的類中直接使用Web層的類。
Qi4j支持的結構
Qi4j目前已經能為LMM提供明確的支持，這有助於規范團隊中開發人員的行為 。Qi4j應用結構是一個小規則集：
結構
所有結構在應用啟動時靜態聲明
所有Composite實例都有所屬模塊
所有服務都有所屬模塊
所有模塊都有所屬層
所有層都有上下層次關系（但不循環）
所有層一起構成了應用
訪問
模塊能訪問同層的所有其他模塊
層能訪問它的直接下級層（不能躍層訪問）
可見性
Composite實例缺省只在所屬模塊內可見
Composite實例也能設置為在層內或層間可見
看起來比較復雜，其實不然。本質上，Composite實例在創建它們的模塊中都 是私有的，除非顯式聲明為對模塊外或層外公開。這和在普通Java中使用 “public”和“pirvate”修飾詞限定類的可見性是類似的。
Qi4j目前尚不提供其他可供選擇的結構，但其包含了構造常用應用程序結構的 簡單方法（包括一個層中只包含一個模塊的情況）。
結構的使用
領域代碼無需了解應用程序結構，但可以用@Structure注解的形式出現。如下 例所示：
CompositeBuilderFactory將在創建時被注入Mixin，而且它僅允許代碼實例化 結構中可見的Composite。
結構發揮作用的另一個常見例子發生在查找服務時。若在相同模塊中有且僅有 一個要求類型的服務，那麼就無需引入額外裝配（Assembly）。服務的使用變得 十分簡單。
例如，如果服務GenericInventory被聲明在Bread模塊中，那麼每個inventory 服務實例都將受其鄰近各自客戶端的程度約束。
應用結構的生成
Qi4j 應用需通過應用程序代碼實現自舉，最簡單的啟動方法大致如下：
另外，還可利用SingletonAssembler編寫上述功能：
SingletonAssembler是一個用於創建單層單模塊Qi4j應用程序的工具類。
newApplication()方法也可接收Assembly[][][]類型的參數，由此可創建“千 層餅式”分層結構的應用環境（除了第一個和最後一個層，其他都有相鄰的上、 下層）。例如：
上面代碼實現的結構如下圖示：
最後，如果應用程序結構十分復雜，還可將ApplicationAssembly實例作為參 數傳遞給newApplication()方法。 ApplicationAssembly用類似迭代的形式創建 全部LayerAssembly，再為每個LayerAssembly創建 ModuleAssembly。舉例如下：
運行上面代碼可得到如下結構：
結構化的好處
通過代碼顯式實現應用程序結構有兩個顯著的好 處：
就近訪問。
架構強制執行。
這意味著，越近的 Composite優先級越高，越易訪問；外部不能訪問模塊或層內私有的Composite。 因為服務被實現為Composite，其解析方法更為含蓄，需要的裝配配置也少得多。
Qi4j結構概念的另一個有趣之處在於每個應用都有一個靜態結構組合，它 可以通過工具來抽取並展示，而不必單獨維護。這使得架構師、設計師或團隊負 責人可輕松跟蹤開發人員對架構的遵循情況，很容易找到越軌者。
總結
本文通過實現於Java平台的Qi4j，簡要討論了COP的可行性。我們看到以 傳統OOP觀念實現對象的Composite，是如何更好分離關注點（concerns），從而 提升代碼的質量和復用性的。此外，我們也討論了顯式建模應用結構的思路，這 一結構通常只在紙面上而不是在代碼中定義。通過顯式建模應用結構，我們可以 更容易落實架構執行並消除服務間的相互依賴。這將幫助我們創建更大規模的系 統，而且隨著引入越來越多的組件及服務，我們的系統不至被其自身的“重 量”壓垮。
最後要強調的一點是，COP和Qi4j中的絕大多數理念並非 前無古人。我們現在做的，恰恰是在前人編程實踐和各種框架中尋找各種優秀的 思想和模式，並提煉出那些我們認為在編寫軟件及保持容易理解且易於維護方面 都能給開發者提供幫助的內容。無論是開發軟件還是我們的日常生活中，將古老 的東西運用於新的環境都是非常重要的。
作者簡介
Rickard Öberg曾參與過多個J2EE開源項目的開發工作，如JBoss、XDoclet和WebWork 。他也是SiteVision CMS/portal平台（以AOP為基礎）的首席架構師。現在服務 於Jayway，主要關注方向是在新一輪以互聯網為中心的應用中廣泛采用的面向領 域軟件開發技術。
Jayway 簡介
Jayway是瑞典一家擁有90位認證 Java專家的一流Java公司。我們的服務范圍包括：內部開發、專業咨詢以及Java 平台相關指導與培訓。我們對開源軟件有堅定信念，並正為大量開源項目積極工 作。我們珍視知識的交流與共享。Jayway的網站是www.jayway.com。
