※ 引述《[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