Re: [問題] 反design pattern的見解

[mgtsai (戰車引擎保修官)]

我想討論這個問題，不過，我不太想在這裡把討論的層級拉太高
所以，就拿一個我自己過去所接過的案件當作實際案例來當作一個小小 case study

就以 Visitor pattern 而言，在 GoF 那本書中已經講得很清楚
我就不用再贅述

不過，在我多次的案件實作過程中，在使用 Visitor pattern 時
會遇上一個讓我覺得不太算是麻煩的小問題

* * * * * * * * * *

就以我過去的經驗而言，使用 Visitor pattern 的時機
有七八成以上是用於不同型態 node tree 的 traversal
（通常會另外配合 Iterator pattern 實作）
而在 visit 每一個節點時，有許多時機，會需要其它資訊
比如，該 visitor 倒底位於 tree 中的哪個位置
或者該 visitor 過去的足跡等。

當有這類的需求時，這意味著，必須額外準備一個變數
記載該位 visitor 在此次的 tree traversal 中，訪問到某個節點時的暫時性狀態。
而這個狀態數變就在這次 traversal 的過程中才會用到
當 tree traversal 結束後，這個狀態變數就不再使用

* * * * * * * * * *

如果完全依 GoF 的 Visitor pattern 的實作法則而言
像上述 tree traversal 所使用的狀態變數
可以 hacking 在 visitor class 的 property 中
但，這樣做可能會有些問題，同一 visitor 由於可能進行不同的任務
在進行各種類型的各別任務時，所使用的狀態變數型別都不一樣
如果把這些不一樣的狀態變數，都一一列為 visitor 的 property 時
這時，就完全破壞了 visitor class 的封裝性
（試想，如果要進行一兩百項任務，visitor 要列出對應的一兩百個 property
  再準備對應的一堆 accessor methods，那 visitor class 倒底長成什麼得性）

所以，在我真正的實作中，就沒有完全按照 GoF 所列的那個 Visitor pattern
而是稍加變形，把 traversal 狀態變數從 visitor class 中抽離出
再將此狀態變數當作 accept() 的參數丟入對應的 method implementation 處理

* * * * * * * * * *

就以這個在我過去的實際經驗中所經常遇見的狀況而言
GoF 中的 Visitor pattern 是給我一個方向上的指引
但在實際的應用中，仍得根據實際的狀況，做某種程度的調整修改

* * * * * * * * * *

要我說什麼心得，我倒沒有什麼特殊意見
畢竟這篇文章的著手處是從單一的 case 下手
而不是以站在高空往下看的角度來看問題

不過，多多討論在真實案例中，對於各種 design pattern 的實際實作情形的討論
也可以作為一個討論主軸，實際檢討落實 design pattern 所遇到的種種問題


--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 210.208.46.43
※ 編輯: mgtsai          來自: 210.208.46.43        (02/10 06:25)
推 tinlans:我有點好奇，你是不是讓 visitor 做太多事情了，並不一定
→ tinlans:所有的事情都要給 Accept() 轉呼叫的東西通通做完吧，
→ tinlans:反正會選用 visitor 的時候，已經決定破壞被 visit 對象
→ tinlans:的封裝性了，你可以把相關的資訊記錄在這兩者之外的地方。
→ tinlans:包括需要這些資訊才能完成的動作，也一併抽出 visitor。
推 YuYuHo:vistor visit house,我覺得vistor最大的缺點
→ YuYuHo:是帶給house太大的負擔
→ YuYuHo:打錯字了,是visitor,剛打完麻將回來,win~~ya~~
→ YuYuHo:假如說house的內部節點其實是不穩定的型態,結果會造成
→ YuYuHo:visitor的介面也變得很不穩定,很容易就搞得一團亂
→ YuYuHo:通常採用visitor時,house本身的結構可能就很複雜了,
→ YuYuHo:這時候還要管理節點的分派策略,還要維持節點穩定,
→ YuYuHo:這表示house做好後就不能隨便更動,很容易牽一髮動全身.