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