※ 引述《H45 (!H45)》之銘言： : 我想封裝性並不全然消失 : -- : 推 tinlans:其實我要說的破壞封裝性，是指 house 被迫 open 給 02/12 15:26 : → tinlans:visitor 的部分，因為 visitor 本身跟 house 是分離的。 02/12 15:27 我的觀點是，封裝性須要利用一些方式加以處理 如果封得太死的話，反而會引發出一些麻煩 一般而言，面對不同模組之間的封裝性問題 我自己會依賴 Facade 來處理 至於模組內部各 class 之間，我就不太要求一定要封裝 在這樣的原則下，我會對 class 結構區分為兩類： * 一類為結構類 class，作為系統運作時資料面的結構 * 一類為行為類 class，定義操作結構類 class 時的動作與過程 在一般的應用中，結構類 class 由於在模組內被廣泛使用 我自己的作法是不封裝結構類 class，模組內的所有 class 都知曉整個結構 這樣子作的用意是，相對而言，結構還是比較不會變動 而行為部分則會因為系統功能的多寡而隨之變動 （比如客戶會多要求，能不能統計某某某資訊之類的需求） 面對這種需要開高彈性的地方，我會把它擺進行為類 class 中處理 而當遇到需要 Visitor pattern 的時機 幾乎都是針對結構類 class 進行 traversal 在這種情況下，配合我針對這兩類 class 的處理原則 使用 Visitor pattern 所遇到的封裝性破壞問題，就不再是重點 反正資類面的結構就是公開來讓模組內的所有 class 知曉 如果，還是得要加以封裝的話 這時可能得要用上 Mediator pattern 來隱藏結構性的問題 不過，當問題處理到這種層級時，就有點過於複雜 如果案件規模沒有大到一定的程度，這種搞法，就有點殺雞用牛刀的感覺 先講到這裡 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 60.245.88.236