23種設計模式之訪問者模式

定義：封裝某些作用於某種資料結構中各元素的操作，它可以在不改變資料結構的前提下定義作用於這些元素的新的操作。

型別：行為類模式

類圖：

訪問者模式可能是行為類模式中最複雜的一種模式了，但是這不能成為我們不去掌握它的理由。我們首先來看一個簡單的例子，程式碼如下：

class A {
	public void method1(){
		System.out.println("我是A");
	}

	public void method2(B b){
		b.showA(this);
	}
}

class B {
	public void showA(A a){
		a.method1();
	}
}

我們主要來看一下在類A中，方法method1和方法method2的區別在哪裡，方法method1很簡單，就是列印出一句“我是A”；方法method2稍微複雜一點，使用類B作為引數，並呼叫類B的showA方法。再來看一下類B的showA方法，showA方法使用類A作為引數，然後呼叫類A的method1方法，可以看到，method2方法繞來繞去，無非就是呼叫了一下自己的method1方法而已，它的執行結果應該也是“我是A”，分析完之後，我們來執行一下這兩個方法，並看一下執行結果：

public class Test {
	public static void main(String[] args){
		A a = new A();
		a.method1();
		a.method2(new B());
	}
}

執行結果為：

我是A
我是A

看懂了這個例子，就理解了訪問者模式的90%，在例子中，對於類A來說，類B就是一個訪問者。但是這個例子並不是訪問者模式的全部，雖然直觀，但是它的可擴充套件性比較差，下面我們就來說一下訪問者模式的通用實現，通過類圖可以看到，在訪問者模式中，主要包括下面幾個角色：

•  抽象訪問者：抽象類或者介面，宣告訪問者可以訪問哪些元素，具體到程式中就是visit方法中的引數定義哪些物件是可以被訪問的。
• 訪問者：實現抽象訪問者所宣告的方法，它影響到訪問者訪問到一個類後該幹什麼，要做什麼事情。
• 抽象元素類：介面或者抽象類，宣告接受哪一類訪問者訪問，程式上是通過accept方法中的引數來定義的。抽象元素一般有兩類方法，一部分是本身的業務邏輯，另外就是允許接收哪類訪問者來訪問。
• 元素類：實現抽象元素類所宣告的accept方法，通常都是visitor.visit(this)，基本上已經形成一種定式了。
• 結構物件：一個元素的容器，一般包含一個容納多個不同類、不同介面的容器，如List、Set、Map等，在專案中一般很少抽象出這個角色。

訪問者模式的通用程式碼實現

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<Element> getList(){
		List<Element> list = new ArrayList<Element>();
		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<Element> list = ObjectStruture.getList();
		for(Element e: list){
			e.accept(new Visitor());
		}
	}
}

訪問者模式的優點

• 符合單一職責原則：凡是適用訪問者模式的場景中，元素類中需要封裝在訪問者中的操作必定是與元素類本身關係不大且是易變的操作，使用訪問者模式一方面符合單一職責原則，另一方面，因為被封裝的操作通常來說都是易變的，所以當發生變化時，就可以在不改變元素類本身的前提下，實現對變化部分的擴充套件。
• 擴充套件性良好：元素類可以通過接受不同的訪問者來實現對不同操作的擴充套件。

訪問者模式的適用場景

假如一個物件中存在著一些與本物件不相干（或者關係較弱）的操作，為了避免這些操作汙染這個物件，則可以使用訪問者模式來把這些操作封裝到訪問者中去。

假如一組物件中，存在著相似的操作，為了避免出現大量重複的程式碼，也可以將這些重複的操作封裝到訪問者中去。

但是，訪問者模式並不是那麼完美，它也有著致命的缺陷：增加新的元素類比較困難。通過訪問者模式的程式碼可以看到，在訪問者類中，每一個元素類都有它對應的處理方法，也就是說，每增加一個元素類都需要修改訪問者類（也包括訪問者類的子類或者實現類），修改起來相當麻煩。也就是說，在元素類數目不確定的情況下，應該慎用訪問者模式。所以，訪問者模式比較適用於對已有功能的重構，比如說，一個專案的基本功能已經確定下來，元素類的資料已經基本確定下來不會變了，會變的只是這些元素內的相關操作，這時候，我們可以使用訪問者模式對原有的程式碼進行重構一遍，這樣一來，就可以在不修改各個元素類的情況下，對原有功能進行修改。

總結

正如《設計模式》的作者GoF對訪問者模式的描述：大多數情況下，你並需要使用訪問者模式，但是當你一旦需要使用它時，那你就是真的需要它了。當然這只是針對真正的大牛而言。在現實情況下（至少是我所處的環境當中），很多人往往沉迷於設計模式，他們使用一種設計模式時，從來不去認真考慮所使用的模式是否適合這種場景，而往往只是想展示一下自己對物件導向設計的駕馭能力。程式設計時有這種心理，往往會發生濫用設計模式的情況。所以，在學習設計模式時，一定要理解模式的適用性。必須做到使用一種模式是因為了解它的優點，不使用一種模式是因為了解它的弊端；而不是使用一種模式是因為不瞭解它的弊端，不使用一種模式是因為不瞭解它的優點。