鍍金池/ 教程/ Java/ 訪(fǎng)問(wèn)者模式
訪(fǎng)問(wèn)者模式
訪(fǎng)問(wèn)者模式討論篇:java的動(dòng)態(tài)綁定與雙分派
責任連模式
迭代器模式
策略模式
命令模式
單例模式
建造者模式
解釋器模式
工廠(chǎng)方法模式
備忘錄模式
原型模式
單例模式討論篇:?jiǎn)卫J脚c垃圾回收
觀(guān)察者模式
模版方法模式
創(chuàng )建類(lèi)模式總結篇
抽象工廠(chǎng)模式
中介者模式

訪(fǎng)問(wèn)者模式

定義:封裝某些作用于某種數據結構中各元素的操作,它可以在不改變數據結構的前提下定義作用于這些元素的新的操作。

類(lèi)型:行為類(lèi)模式

類(lèi)圖:

http://wiki.jikexueyuan.com/project/java-design-pattern/images/visitor-pattern-1.jpg" alt="visitor-pattern" />

訪(fǎng)問(wèn)者模式可能是行為類(lèi)模式中最復雜的一種模式了,但是這不能成為我們不去掌握它的理由。我們首先來(lái)看一個(gè)簡(jiǎn)單的例子,代碼如下:

    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();
        }
    }

我們主要來(lái)看一下在類(lèi)A中,方法method1和方法method2的區別在哪里,方法method1很簡(jiǎn)單,就是打印出一句"我是A";方法method2稍微復雜一點(diǎn),使用類(lèi)B作為參數,并調用類(lèi)B的showA方法。再來(lái)看一下類(lèi)B的showA方法,showA方法使用類(lèi)A作為參數,然后調用類(lèi)A的method1方法,可以看到,method2方法繞來(lái)繞去,無(wú)非就是調用了一下自己的method1方法而已,它的運行結果應該也是"我是A",分析完之后,我們來(lái)運行一下這兩個(gè)方法,并看一下運行結果:

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

運行結果為:

我是A
我是A

看懂了這個(gè)例子,就理解了訪(fǎng)問(wèn)者模式的90%,在例子中,對于類(lèi)A來(lái)說(shuō),類(lèi)B就是一個(gè)訪(fǎng)問(wèn)者。但是這個(gè)例子并不是訪(fǎng)問(wèn)者模式的全部,雖然直觀(guān),但是它的可擴展性比較差,下面我們就來(lái)說(shuō)一下訪(fǎng)問(wèn)者模式的通用實(shí)現,通過(guò)類(lèi)圖可以看到,在訪(fǎng)問(wèn)者模式中,主要包括下面幾個(gè)角色:

  • 抽象訪(fǎng)問(wèn)者:抽象類(lèi)或者接口,聲明訪(fǎng)問(wèn)者可以訪(fǎng)問(wèn)哪些元素,具體到程序中就是visit方法中的參數定義哪些對象是可以被訪(fǎng)問(wèn)的。
  • 訪(fǎng)問(wèn)者:實(shí)現抽象訪(fǎng)問(wèn)者所聲明的方法,它影響到訪(fǎng)問(wèn)者訪(fǎng)問(wèn)到一個(gè)類(lèi)后該干什么,要做什么事情。
  • 抽象元素類(lèi):接口或者抽象類(lèi),聲明接受哪一類(lèi)訪(fǎng)問(wèn)者訪(fǎng)問(wèn),程序上是通過(guò)accept方法中的參數來(lái)定義的。抽象元素一般有兩類(lèi)方法,一部分是本身的業(yè)務(wù)邏輯,另外就是允許接收哪類(lèi)訪(fǎng)問(wèn)者來(lái)訪(fǎng)問(wèn)。
  • 元素類(lèi):實(shí)現抽象元素類(lèi)所聲明的accept方法,通常都是visitor.visit(this),基本上已經(jīng)形成一種定式了。
  • 結構對象:一個(gè)元素的容器,一般包含一個(gè)容納多個(gè)不同類(lèi)、不同接口的容器,如List、Set、Map等,在項目中一般很少抽象出這個(gè)角色。

    訪(fǎng)問(wèn)者模式的通用代碼實(shí)現

    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());
            }
        }
    }

訪(fǎng)問(wèn)者模式的優(yōu)點(diǎn)

  • 符合單一職責原則:凡是適用訪(fǎng)問(wèn)者模式的場(chǎng)景中,元素類(lèi)中需要封裝在訪(fǎng)問(wèn)者中的操作必定是與元素類(lèi)本身關(guān)系不大且是易變的操作,使用訪(fǎng)問(wèn)者模式一方面符合單一職責原則,另一方面,因為被封裝的操作通常來(lái)說(shuō)都是易變的,所以當發(fā)生變化時(shí),就可以在不改變元素類(lèi)本身的前提下,實(shí)現對變化部分的擴展。
  • 擴展性良好:元素類(lèi)可以通過(guò)接受不同的訪(fǎng)問(wèn)者來(lái)實(shí)現對不同操作的擴展。

訪(fǎng)問(wèn)者模式的適用場(chǎng)景

假如一個(gè)對象中存在著(zhù)一些與本對象不相干(或者關(guān)系較弱)的操作,為了避免這些操作污染這個(gè)對象,則可以使用訪(fǎng)問(wèn)者模式來(lái)把這些操作封裝到訪(fǎng)問(wèn)者中去。

假如一組對象中,存在著(zhù)相似的操作,為了避免出現大量重復的代碼,也可以將這些重復的操作封裝到訪(fǎng)問(wèn)者中去。

但是,訪(fǎng)問(wèn)者模式并不是那么完美,它也有著(zhù)致命的缺陷:增加新的元素類(lèi)比較困難。通過(guò)訪(fǎng)問(wèn)者模式的代碼可以看到,在訪(fǎng)問(wèn)者類(lèi)中,每一個(gè)元素類(lèi)都有它對應的處理方法,也就是說(shuō),每增加一個(gè)元素類(lèi)都需要修改訪(fǎng)問(wèn)者類(lèi)(也包括訪(fǎng)問(wèn)者類(lèi)的子類(lèi)或者實(shí)現類(lèi)),修改起來(lái)相當麻煩。也就是說(shuō),在元素類(lèi)數目不確定的情況下,應該慎用訪(fǎng)問(wèn)者模式。所以,訪(fǎng)問(wèn)者模式比較適用于對已有功能的重構,比如說(shuō),一個(gè)項目的基本功能已經(jīng)確定下來(lái),元素類(lèi)的數據已經(jīng)基本確定下來(lái)不會(huì )變了,會(huì )變的只是這些元素內的相關(guān)操作,這時(shí)候,我們可以使用訪(fǎng)問(wèn)者模式對原有的代碼進(jìn)行重構一遍,這樣一來(lái),就可以在不修改各個(gè)元素類(lèi)的情況下,對原有功能進(jìn)行修改。


總結

正如《設計模式》的作者GoF對訪(fǎng)問(wèn)者模式的描述:大多數情況下,你并需要使用訪(fǎng)問(wèn)者模式,但是當你一旦需要使用它時(shí),那你就是真的需要它了。當然這只是針對真正的大牛而言。在現實(shí)情況下(至少是我所處的環(huán)境當中),很多人往往沉迷于設計模式,他們使用一種設計模式時(shí),從來(lái)不去認真考慮所使用的模式是否適合這種場(chǎng)景,而往往只是想展示一下自己對面向對象設計的駕馭能力。編程時(shí)有這種心理,往往會(huì )發(fā)生濫用設計模式的情況。所以,在學(xué)習設計模式時(shí),一定要理解模式的適用性。必須做到使用一種模式是因為了解它的優(yōu)點(diǎn),不使用一種模式是因為了解它的弊端;而不是使用一種模式是因為不了解它的弊端,不使用一種模式是因為不了解它的優(yōu)點(diǎn)。