定義：封裝某些作用于某種數據結構中(zhōng)各元素的操作，它可以在不改變數據結構的前提下(xià)定義作用于這些元素的新的操作。
類型：行爲類模式
類圖：
訪問者模式可能是行爲類模式中(zhōng)最複雜(zá)的一(yī)種模式了，但是這不能成爲我(wǒ)們不去(qù)掌握它的理由。我(wǒ)們首先來看一(yī)個簡單的例子，代碼如下(xià)：
class A {
public void method1(){
System.out.println("我(wǒ)是A");
}
public void method2(B b){
b.showA(this);
}
}
class B {
public void showA(A a){
a.method1();
}
}我(wǒ)們主要來看一(yī)下(xià)在類A中(zhōng)，方法method1和方法method2的區别在哪裏，方法method1很簡單，就是打印出一(yī)句"我(wǒ)是A"；方法method2稍微複雜(zá)一(yī)點，使用類B作爲參數，并調用類B的showA方法。再來看一(yī)下(xià)類B的showA方法，showA方法使用類A作爲參數，然後調用類A的method1方法，可以看到，method2方法繞來繞去(qù)，無非就是調用了一(yī)下(xià)自己的method1方法而已，它的運行結果應該也是"我(wǒ)是A"，分(fēn)析完之後，我(wǒ)們來運行一(yī)下(xià)這兩個方法，并看一(yī)下(xià)運行結果：
public class Test {
public static void main(String[] args){
A a = new A();
a.method1();
a.method2(new B());
}
}運行結果爲：
我(wǒ)是A
我(wǒ)是A
看懂了這個例子，就理解了訪問者模式的90%，在例子中(zhōng)，對于類A來說，類B就是一(yī)個訪問者。但是這個例子并不是訪問者模式的全部，雖然直觀，但是它的可擴展性比較差，下(xià)面我(wǒ)們就來說一(yī)下(xià)訪問者模式的通用實現，通過類圖可以看到，在訪問者模式中(zhōng)，主要包括下(xià)面幾個角色：
抽象訪問者：抽象類或者接口，聲明訪問者可以訪問哪些元素，具體(tǐ)到程序中(zhōng)就是visit方法中(zhōng)的參數定義哪些對象是可以被訪問的。
訪問者：實現抽象訪問者所聲明的方法，它影響到訪問者訪問到一(yī)個類後該幹什麽，要做什麽事情。
抽象元素類：接口或者抽象類，聲明接受哪一(yī)類訪問者訪問，程序上是通過accept方法中(zhōng)的參數來定義的。抽象元素一(yī)般有兩類方法，一(yī)部分(fēn)是本身的業務邏輯，另外(wài)就是允許接收哪類訪問者來訪問。
元素類：實現抽象元素類所聲明的accept方法，通常都是visitor.visit(this)，基本上已經形成一(yī)種定式了。
結構對象：一(yī)個元素的容器，一(yī)般包含一(yī)個容納多個不同類、不同接口的容器，如List、Set、Map等，在項目中(zhōng)一(yī)般很少抽象出這個角色。
訪問者模式的通用代碼實現
abstract class Element {
public abstract void accept(IVisitor visitor);
public abstract void doSomething();
}
interface IVisitor {
public void visit(ConcreteElement1 el1);
public void visit(ConcreteElement2 el2);
}
class ConcreteElement1 extends Element {
public void doSomething(){
System.out.println("這是元素1");
}
public void accept(IVisitor visitor) {
visitor.visit(this);
}
}
class ConcreteElement2 extends Element {
public void doSomething(){
System.out.println("這是元素2");
}
public void accept(IVisitor visitor) {
visitor.visit(this);
}
}
class Visitor implements IVisitor {
public void visit(ConcreteElement1 el1) {
el1.doSomething();
}
public void visit(ConcreteElement2 el2) {
el2.doSomething();
}
}
class ObjectStruture {
public static List getList(){
List list = new ArrayList();
Random ran = new Random();
for(int i=0; i<10; i++){
int a = ran.nextInt(100);
if(a>50){
list.add(new ConcreteElement1());
}else{
list.add(new ConcreteElement2());
}
}
return list;
}
}
public class Client {
public static void main(String[] args){
List list = ObjectStruture.getList();
for(Element e: list){
e.accept(new Visitor());
}
}
}訪問者模式的優點
符合單一(yī)職責原則：凡是适用訪問者模式的場景中(zhōng)，元素類中(zhōng)需要封裝在訪問者中(zhōng)的操作必定是與元素類本身關系不大(dà)且是易變的操作，使用訪問者模式一(yī)方面符合單一(yī)職責原則，另一(yī)方面，因爲被封裝的操作通常來說都是易變的，所以當發生(shēng)變化時，就可以在不改變元素類本身的前提下(xià)，實現對變化部分(fēn)的擴展。
擴展性良好：元素類可以通過接受不同的訪問者來實現對不同操作的擴展。
訪問者模式的适用場景
假如一(yī)個對象中(zhōng)存在着一(yī)些與本對象不相幹（或者關系較弱）的操作，爲了避免這些操作污染這個對象，則可以使用訪問者模式來把這些操作封裝到訪問者中(zhōng)去(qù)。
假如一(yī)組對象中(zhōng)，存在着相似的操作，爲了避免出現大(dà)量重複的代碼，也可以将這些重複的操作封裝到訪問者中(zhōng)去(qù)。
但是，訪問者模式并不是那麽完美，它也有着緻命的缺陷：增加新的元素類比較困難。通過訪問者模式的代碼可以看到，在訪問者類中(zhōng)，每一(yī)個元素類都有它對應的處理方法，也就是說，每增加一(yī)個元素類都需要修改訪問者類（也包括訪問者類的子類或者實現類），修改起來相當麻煩。也就是說，在元素類數目不确定的情況下(xià)，應該慎用訪問者模式。所以，訪問者模式比較适用于對已有功能的重構，比如說，一(yī)個項目的基本功能已經确定下(xià)來，元素類的數據已經基本确定下(xià)來不會變了，會變的隻是這些元素内的相關操作，這時候，我(wǒ)們可以使用訪問者模式對原有的代碼進行重構一(yī)遍，這樣一(yī)來，就可以在不修改各個元素類的情況下(xià)，對原有功能進行修改。
總結
正如《設計模式》的作者GoF對訪問者模式的描述：大(dà)多數情況下(xià)，你并需要使用訪問者模式，但是當你一(yī)旦需要使用它時，那你就是真的需要它了。當然這隻是針對真正的大(dà)牛而言。在現實情況下(xià)（至少是我(wǒ)所處的環境當中(zhōng)），很多人往往沉迷于設計模式，他們使用一(yī)種設計模式時，從來不去(qù)認真考慮所使用的模式是否适合這種場景，而往往隻是想展示一(yī)下(xià)自己對面向對象設計的駕馭能力。編程時有這種心理，往往會發生(shēng)濫用設計模式的情況。所以，在學習設計模式時，一(yī)定要理解模式的适用性。必須做到使用一(yī)種模式是因爲了解它的優點，不使用一(yī)種模式是因爲了解它的弊端；而不是使用一(yī)種模式是因爲不了解它的弊端，不使用一(yī)種模式是因爲不了解它的優點。
