一、引子

對于系統(tǒng)中一個已經(jīng)完成的類層次結(jié)構(gòu)，我們已經(jīng)給它提供了滿足需求的接口。但是面對新增加的需求，我們應(yīng)該怎么做呢？如果這是為數(shù)不多的幾次變動，而且你不用為了一個需求的調(diào)整而將整個類層次結(jié)構(gòu)統(tǒng)統(tǒng)地修改一遍，那么直接在原有類層次結(jié)構(gòu)上修改也許是個不錯的主意。

但是往往我們遇到的卻是：這樣的需求變動也許會不停的發(fā)生；更重要的是需求的任何變動可能都要讓你將整個類層次結(jié)構(gòu)修改個底朝天……。這種類似的操作分布在不同的類里面，不是一個好現(xiàn)象，我們要對這個結(jié)構(gòu)重構(gòu)一下了。

那么，訪問者模式也許是你很好的選擇。

二、定義與結(jié)構(gòu)

訪問者模式，顧名思義使用了這個模式后就可以在不修改已有程序結(jié)構(gòu)的前提下，通過添加額外的“訪問者”來完成對已有代碼功能的提升。

《設(shè)計模式》一書對于訪問者模式給出的定義為：表示一個作用于某對象結(jié)構(gòu)中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。從定義可以看出結(jié)構(gòu)對象是使用訪問者模式必須條件，而且這個結(jié)構(gòu)對象必須存在遍歷自身各個對象的方法。這便類似于Java中的collection概念了。

以下是訪問者模式的組成結(jié)構(gòu)：

1) 訪問者角色（Visitor）：為該對象結(jié)構(gòu)中具體元素角色聲明一個訪問操作接口。該操作接口的名字和參數(shù)標(biāo)識了發(fā)送訪問請求給具體訪問者的具體元素角色。這樣訪問者就可以通過該元素角色的特定接口直接訪問它。

2) 具體訪問者角色（Concrete Visitor）：實(shí)現(xiàn)每個由訪問者角色（Visitor）聲明的操作。

3) 元素角色（Element）：定義一個Accept操作，它以一個訪問者為參數(shù)。

4) 具體元素角色（Concrete Element）：實(shí)現(xiàn)由元素角色提供的Accept操作。

5) 對象結(jié)構(gòu)角色（Object Structure）：這是使用訪問者模式必備的角色。它要具備以下特征：能枚舉它的元素；可以提供一個高層的接口以允許該訪問者訪問它的元素；可以是一個復(fù)合（組合模式）或是一個集合，如一個列表或一個無序集合。

那么像引言中假想的。我們應(yīng)該做些什么才能讓訪問者模式跑起來呢？首先我們要在原有的類層次結(jié)構(gòu)中添加accept方法。然后將這個類層次中的類放到一個對象結(jié)構(gòu)中去。這樣再去創(chuàng)建訪問者角色……

三、雙重分派

對了，你在上面的例子中體會到雙重分派的實(shí)現(xiàn)了沒有？

首先在客戶程序中將具體訪問者模式作為參數(shù)傳遞給具體元素角色（加亮的地方所示）。這便完成了一次分派。

進(jìn)入具體元素角色后，具體元素角色調(diào)用作為參數(shù)的具體訪問者模式中的visitor方法，同時將自己（this）作為參數(shù)傳遞進(jìn)去。具體訪問者模式再根據(jù)參數(shù)的不同來選擇方法來執(zhí)行（加亮的地方所示）。這便完成了第二次分派。

四、總結(jié)

這是一個巧妙而且復(fù)雜的模式，它的使用條件比較苛刻。當(dāng)系統(tǒng)中存在著固定的數(shù)據(jù)結(jié)構(gòu)（比如上面的類層次），而有著不同的行為，那么訪問者模式也許是個不錯的選擇。