U25 再看簡單型的Component

以往的Method註解用途只用來存放說明、參數、傳回值與例外，在這個情況下方法意義的區分（指給處理程式用的）只能靠Class的佈置來達成，但是現在的註解已經可以盛裝更大量的資訊，我們就可以將原先分為六大部分其中的流程控制類（Flow與Action）再回歸為一個Class──只要能夠在Method註解裡區分其意義即可。

在元件裡流程控制相關的方法類型有以下五種（第一種放在Implementation），在註解裡定義一個方法類型欄位就能在處理程式裡取得對應值。
●Implementation Method（入口方法）
●Flow Method且被Implementation Method直接呼叫（被入口方法呼叫的流程方法）
●Flow Method但只被Flow Method呼叫（內部流程方法）
●Action Method且被Flow Method直接呼叫（被流程方法呼叫的動作方法）
●Action Method但只被Action Method呼叫（內部動作方法）

元件設計回歸到這樣的簡單結構在設計上已經很接近現在的主流作法，製作流程方法時毌須浪費時間在與結構佈置有關的行為，唯一需要作的是依註解規定撰寫應該有的註解內容──然而這本來就是應該做的事。至此，我們能夠在不多花費設計時間的前提下完成滿足以軟體工廠為前提的元件設計。

我會為了容易編輯註解的目的製作一個編輯器，除了可以把註解內容（多行文字）直覺地以UI欄位再編修之外，還可以詳細定義註解所要編輯的屬性並檢查值是否合法，設計人員只需要依畫面提示輸入註解內容而不用去注意註解的格式，便能得到符合規定的註解內容。另外還需要改寫Java編輯器，增加註解可收合或展開的功能，不然混雜著一大堆的程式碼雖然容易看懂卻也很難看清楚。

註：有些元件的Flow會因客戶的需要而有很大的不同，這種元件一定要用結構型的方式設計。因為唯有明確地知道Action、Model與Properties的全部範圍才有可能作最佳的設計，同時避免掉繼承後override多次後的混亂。另一種類型像基本Data Model讀寫器那樣Action有不同的實作，這也應該將Flow與Action分開放置。