我想討論這個問題，不過，我不太想在這裡把討論的層級拉太高 所以，就拿一個我自己過去所接過的案件當作實際案例來當作一個小小 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)