3 6 複製被監視資料

場景

有一些領域資料置身於gui控制項中，而業務處理函式需要訪問這些資料。

將該資料複製到乙個業務物件中。建立乙個observe模式，用以同步業務物件和gui物件內的重複資料。

動機乙個分層良好的系統，應該將處理使用者介面（gui）和處理業務邏輯（business logic）的**分開。之所以這樣做，原因有以下幾點：

(1) 你可能需要使用若干個不同的使用者介面來表現相同的業務邏輯。如果同時承擔兩種責任，使用者介面會變得過分複雜。

(2) 與gui隔離之後，業務類的維護和演化都會更容易；你甚至可以讓不同的開發者負責不同部分的開發。

儘管你可以輕鬆地將「行為」劃分到不同部位，「資料」卻往往不能如此。同一筆資料有可能既需要內嵌於gui控制項，也需要儲存於業務模型裡。

自從mvc（model-view-controller）模式出現後，使用者介面框架都使用多層系統（multitiered system）來提供某種機制，使你不但可以提供這類資料，並保持它們同步（sync）。

如果你遇到的**是以雙層（two-tiered）方式開發，業務邏輯（business logic）被內嵌於使用者介面（ui）之中，你就有必要將行為分離出來。

其中的主要工作就是函式的分解和搬移。但資料就不同了：不能僅僅只是移動資料，你必須將它複製到新建模組中，並提供相應的同步機制。

做法1、修改展現類（presentation class），使其成為業務類（domain class）的observer[gof]。

1.1 如果尚未有業務類（domain class），就建立乙個。

1.2 如果沒有從展現類（presentation class）到（domain class）的關聯性（link），就將業務類（domain class）儲存於展現類（presentation class）的乙個值域中。

2、針對gui class內的業務資料（domain data），使用自封裝字段（self encapsulate field（171））。

3、編譯，測試。

4、在事件處理函式（event handler）中加上對設值函式（setter）的呼叫，以[直接訪問方式]更新gui元件。

在事件處理函式中放乙個設值函式（setter），利用它將gui元件更新為業務資料（domain data）的當前值。

當然，這其實沒有必要，你只不過是拿它的值設定它自己。但是這樣使用setter，便是允許其中的任何動作得以於日後被執行起來，這是這一步驟的意義所在。

進行這個改變時，對於元件，不要使用取值函式（getter），應該採取[直接取用]方式，因為稍後我們將修改取值函式（getter），使其從業務物件domain object（而非gui元件）取值。

設值函式（setter）也將遭受類似修改。

確保測試**能夠觸發新新增的事件處理（event handling）機制。

5、編譯，測試。

6、在業務類（domain class）中定義資料及其相關訪問函式（accessors）。

確保業務類（domain class）中的設值函式（setter）能夠觸發observer模式的通報機制（notify mechanism）。

對於被觀察（被監視）的資料，在業務類（domain class）中使用[與展現類（presentation class）所用的相同型別]（通常是字串）來儲存。後續重構中你可以自由改變這個資料型別。

7、修改展現類（presentation class）中的訪問函式（accessors），將它們的操作物件改為業務物件（domain object）（而非gui元件）。

8、修改observer的update（），使其從相應的業務物件（domain object）中將所需資料拷貝給gui元件。 (不要使用setter函式)。

9、編譯，測試。

範例暫無

good good study, day day up.

順序選擇迴圈總結