※ 引述《mgtsai (戰車引擎保修官)》之銘言：
: 標題: Re: [問題] 反design pattern的見解
: 時間: Sat Feb 10 06:23:20 2007
: 我想討論這個問題，不過，我不太想在這裡把討論的層級拉太高
: 所以，就拿一個我自己過去所接過的案件當作實際案例來當作一個小小 case study
: --
: 推 tinlans:我有點好奇，你是不是讓 visitor 做太多事情了，並不一定 02/10 16:14
: → tinlans:所有的事情都要給 Accept() 轉呼叫的東西通通做完吧， 02/10 16:15
: → tinlans:反正會選用 visitor 的時候，已經決定破壞被 visit 對象 02/10 16:15
: → tinlans:的封裝性了，你可以把相關的資訊記錄在這兩者之外的地方。 02/10 16:16
: → tinlans:包括需要這些資訊才能完成的動作，也一併抽出 visitor。 02/10 16:17
我自己對 Visitor 的定位，是以比較望文生義的方式來看待
既然是
舉個例子，就以 binary tree traversal
就至少有 pre-order, post-order, in-order 三種
而在進行每項任務時，會使用哪種 traversal 則是依狀況而定
如果把整件事加以區分，我會指定以下機制：
* Iterator 負責 tree traversal 方式
* 實際的任務執行，則於 Visitor 的 implementation class 中實作
(Visitor 本身則為 generic interface)
或者，在 Visitor 中弄個 delegation
把該執行的任務 delegate 到另一個 class hierarchy 裡處理
* Visitor 則純化為：它負責逛節點，藉由 accept() 對手中的任務進行 "分派"
至於逛節點的方式則由 Iterator 定義
至於執行什麼任務則由 implementation/delegation class 中處理
* 至於封裝性的問題，則定義統一的使用介面，弄一個 Facade 供其它模組使用
就如同大家所述，使用 Visitor 時會碰到不少麻煩
甚至要完全依 GoF 的定義結構會碰上釘子
換句話說，雖然我們可以依照 pattern 的大方向進行
但面對實際的應用時，還是得牽就現實狀況，作某種程度的調整
: 推 YuYuHo:vistor visit house,我覺得vistor最大的缺點 02/10 16:18
: → YuYuHo:是帶給house太大的負擔 02/10 16:21
: → YuYuHo:打錯字了,是visitor,剛打完麻將回來,win~~ya~~ 02/10 22:52
: → YuYuHo:假如說house的內部節點其實是不穩定的型態,結果會造成 02/10 22:54
: → YuYuHo:visitor的介面也變得很不穩定,很容易就搞得一團亂 02/10 22:55
: → YuYuHo:通常採用visitor時,house本身的結構可能就很複雜了, 02/10 22:57
: → YuYuHo:這時候還要管理節點的分派策略,還要維持節點穩定, 02/10 23:01
: → YuYuHo:這表示house做好後就不能隨便更動,很容易牽一髮動全身. 02/10 23:02
這個問題，我會在所對應的 Iterator 中加以處理相關的機制
而 Visitor 與其相關的界面，我會盡量固定住而不去動它
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 210.201.190.206