※ 引述《[email protected] (foolish)》之銘言： : ※ 引述《[email protected] (wctang)》之銘言： : > Timer 是排程器，TimerTask 是被排程的對象，表示要執行的工作 : > 這種分別可以達成如同一個工作在不同時間被叫起這樣的用法 : > 如果要說有什麼設計觀點，那或許可以算個最簡單的 Template Method 吧@@ : > BTW, 比較複雜的情況應該要用 quartz. : 昨天稍為"看"了一下新買的Head First Design Pattern的第一章 : 好像就是這個樣子了XD : 我覺得他應該是strategy pattern : 分享一下讀書心得 >///< : strategy pattern在書中放第一章做為起點 : 感覺上很明白並強烈地提示初學者design pattern的大原則 : 把變動與不變動的部分"分開" : 將變動的部分封裝起來，即使將來需要有所變動 : 也不會影響使用個"已被封裝"的演算法的主體 : TaskTimer就是變動的部分 : 他裡面怎麼實作Timer是不去裡會的， : 因為對Timer來說要執行的任務已經封裝在TaskTimer裡 : 只是透過TaskTimer這一種介面(這裡不是指語法上的interface) : 來執行任務(演算法) : 清楚劃分，變動與不變動的部分。使得程式更容易維護與擴充。 從以前到現在, 對於 Template Method、Strategy、Command 這三個 pattern, (或許再加個State?) 我一直覺得他們概念相當接近, 實務上也常可以混用. 讓我常常分不清楚我的實作(或看到的實作)究竟該歸類在那個 pattern. 不過根據我的理解, 我認為 Timer跟TaskTimer 歸類於 Command 會比較恰當. ===================== Template Method : 若一個流程(演算法)有固定幾個可抽換的步驟, 實作其骨架. 如下 : public foo() { random(...) ; // ... sort(...) ; // ... print(...) ; } 要舉實例的話, 可以看 org.apache.struts.action.RequestProcessor.process(...) 其中的各部分實作都是未來可以在子類別中抽換的. 像 processRoles(...) ====================== Strategy 針對處理對象的特性, 採用不同的方式實作, 傳統做法為 if ... else if ... else if ... else ... Strategy 對各種處理方式找出統一的介面, 並分別寫成不同的類別. 如排序實作, 就可以寫 MergeSort, BubbleSort, QuickSort 等不同類別. 根據資料特性, 我們可以選用不同的策略處理排序 (可能搭配一些Creational Patterns) 所以執行者會針對處理對象, 取得適當的 Strategy 物件, 並加以執行. ======================= Command 把包含command的物件, 交付給特定對象負責執行. 執行者並不會考慮個別 Command 的內容. -- BBS 賭徒的 一日生活： PO文 ─＞ P幣收入 ─＞ 賭博 ─┬───＞ 赤貧 ─╮ ︿ ︿ │ 輸球 │ │ │ 贏球│ │ │ ╰────────╯ │ ╰───────────────────────╯ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.92.57.92