25.3 訪問者模式的應用 25.3.1 訪問者模式的優點 ● 符合單一職責原則 具體元素角色也就是Employee抽象類的兩個子類負責數據的加載，而Visitor類則負責報表的展現，兩個不同的職責非常明確地分離開來，各自演繹變化。 ● 優秀的擴展性 由于職責分開，繼續增加對數據的操作是非常快捷的，例如，現在要增加一份給大老板的報表，這份報表格式又有所不同，直接在Visitor中增加一個方法，傳遞數據后進行整理打印。 ● 靈活性非常高 例如，數據匯總，就以剛剛我們說的Employee的例子，如果我現在要統計所有員工的工資之和，怎么計算？把所有人的工資for循環加一遍？是個辦法，那我再提個問題，員工工資×1.2，部門經理×1.4，總經理×1.8，然后把這些工資加起來，你怎么處理？1.2，1.4，1.8是什么？不是吧？！你沒看到領導不論什么時候都比你拿得多，工資獎金就不說了，就是過節發個慰問券也比你多，就是這個系數在作祟。我們繼續說你想怎么統計？使用for循環，然后使用instanceof來判斷是員工還是經理？這可以解決，但不是個好辦法，好辦法是通過訪問者模式來實現，把數據扔給訪問者，由訪問者來進行統計計算。 25.3.2 訪問者模式的缺點 ● 具體元素對訪問者公布細節 訪問者要訪問一個類就必然要求這個類公布一些方法和數據，也就是說訪問者關注了其他類的內部細節，這是迪米特法則所不建議的。 ● 具體元素變更比較困難 具體元素角色的增加、刪除、修改都是比較困難的，就上面那個例子，你想想，你要是想增加一個成員變量，如年齡age，Visitor就需要修改，如果Visitor是一個還好辦，多個呢？業務邏輯再復雜點呢？ ● 違背了依賴倒置轉原則 訪問者依賴的是具體元素，而不是抽象元素，這破壞了依賴倒置原則，特別是在面向對象的編程中，拋棄了對接口的依賴，而直接依賴實現類，擴展比較難。 25.3.3 訪問者模式的使用場景 ● 一個對象結構包含很多類對象，它們有不同的接口，而你想對這些對象實施一些依賴于其具體類的操作，也就說是用迭代器模式已經不能勝任的情景。 ● 需要對一個對象結構中的對象進行很多不同并且不相關的操作，而你想避免讓這些操作“污染”這些對象的類。 總結一下，在這種地方你一定要考慮使用訪問者模式：業務規則要求遍歷多個不同的對象。這本身也是訪問者模式出發點，迭代器模式只能訪問同類或同接口的數據（當然了，如果你使用instanceof，那么能訪問所有的數據，這沒有爭論），而訪問者模式是對迭代器模式的擴充，可以遍歷不同的對象，然后執行不同的操作，也就是針對訪問的對象不同，執行不同的操作。訪問者模式還有一個用途，就是充當攔截器（Interceptor）角色，這個我們將在混編模式中講解。