UI框架的組織模式
The Orgnizing Patterns Of UI Framework

原著：Brian Sun

UI框架中有很多組件，很多類，很多細小而繁多的標準，這些特征使得UI框架成為一個業務邏輯和底層代碼的復雜無序混合體，對它的類組織方式的研究也就顯得特別有模式化編程的意義。

Pattern 1：Composite
    幾乎所有時下流行的UI組件都會遵循Composite模式，比如AWT、Swing、Java2D、SWT、JFace、EclipseUI、 Draw2D、GEF以及.NET世界的Windows Forms。該模式的大概含義是，子組件和母組件是同一個類型的。比如一個Button應該是安排在一個Panel上的，但是Button和Panel可能都是一個Container或者都是一個Composite。

Pattern 2：繪制前組織
    目前公共領域的設計模式還沒有可以精確的表達這個思路的名詞，所以我就自做主張，起了個名字，后面的Pattern如果用中文命名，也是這個原因。該模式的大概含義是，子組件應趕在母組件繪制之前將自己顯式的加入母組件。比如說，如果Button要繼承Panel的某個屬性（我是指Button要得到 Panel的某個知識），那么就要趕在繪制之前顯式的將這個Button對象add到Panel中去。繪制前組織的典型例子是AWT、Swing、 Java2D、Draw2d等。

Pattern 3：構建時組織
    和某種工廠方式相似，構建時組織是在類的構造器上做文章。該模式的大概含義是，子組件在構建時就必須確定它屬于哪個母組件，以便在后面的操作中與母組件戶動。比如Button所有的構建器都要求傳入一個Composite對象作為parent。這個模式與上面的Pattern 2完全不同，其典型例子有SWT、JFace、EclipseUI、GEF（都是一家的）。

Pattern 4：MVC
    幾乎所有時下流行的UI組件都或多或少的使用了MVC，或不太嚴格的MVC，或MVC某個角度的思想。該模式用在UI系統上的大概含義是，將組件的繪制、設置和事件處理分開，在不同的角色中完成。我在本文所舉的所有例子中，只有GEF實現了嚴格和完美的MVC，而AWT、Swing、Java2D等組件（都是由Sun開發或Sun和Netscape合作開發的）則使用了一個著名的同時也是最容易被搞混淆的MVC變種。該變種中也有三個角色，繪圖器代理、無知的模型和監聽器、原型組件和事件處理方法。而微軟的MFC也采用了MVC的另一個著名變種，Document-View，這個變種顯然只有兩個角色。

Pattern 5：Delegate
    性能和可移植性是一直是UI平臺最關注的兩個問題。性能依靠盡量少的載入類，可移植性則依靠對更多圖形庫的支持，這兩件事都需要將硬性的繪圖方法或事件處理方式分離出去，交給代理完成。該模式的含義是，繪圖工具本身不繪圖，它只負責決定應該由它的哪個代理完成，并負責為代理繪制圖形搜集參數。 Eclipse和Sun的主要工具都采用了這一模式，不同的是Eclipse也在事件處理環節應用了代理模式，因為事件被觸發之前沒有理由將它的實現讀入內存，所以實現應該由代理完成。

Pattern 6：Layer
   Eclipse采用了嚴格而完美的分層模型，有嚴格界限的層次至少有三個，分別是org.eclipse.swt, org.eclipse.jface, org.eclipse.ui。其中SWT負責繪制簡單的組件，提供簡單組件的功能。JFace負責繪制復雜交互方式的組件，有些JFace的組件包裝了 SWT的組件，并提供了隨組件而走的服務。這兩個包都可以在Eclipse以外的平臺上使用。UI層則完成Eclipse平臺的主要UI功能，很多地方提供了系統唯一的服務，并包裝了JFace的組件。Draw2D建立在SWT之上，包裝了SWT使其能更好的為繪制二維復雜圖形而服務。GEF建立在 Draw2D和EclipseUI層的基礎之上，為Eclipse Workbench提供某些功能。

本文只涉及了UI架構的組織模式，并未涉及其它模式，關于UI的其它模式會在今后的文章中再次討論，即將出版，敬請留意。這里有很多想法還不太全面，請參與我的討論并提出你的想法，或者增加你的模式。謝謝。

做軟件的泡泡