《JAVA與模式》之訪問者模式

在閻宏博士的《JAVA與模式》一書中開頭是這樣描述訪問者（Visitor）模式的：

　　訪問者模式是對象的行為模式。訪問者模式的目的是封裝一些施加於某種數據結構元素之上的操作。一旦這些操作需要修改的話，接受這個操作的數據結構則可以保持不變。

interface Service {

    public void accept(Visitor visitor);
}

class Visitor {

    public void process(Service service) {
        // 基本業務
        System.out.println("基本業務");
    }

    public void process(Saving service) {
        // 存款
        System.out.println("存款");
    }

    public void process(Draw service) {
        // 提款
        System.out.println("提款");
    }

    public void process(Fund service) {
        System.out.println("基金");
        // 基金
    }

}

class Saving implements Service {

    public void accept(Visitor visitor) {
        visitor.process(this);

    }
}

class Draw implements Service {

    public void accept(Visitor visitor) {
        visitor.process(this);

    }
}

class Fund implements Service {

    public void accept(Visitor visitor) {
        visitor.process(this);

    }
}

從上面例子可以看出,訪問者借助的是java的動態分配機制,使得visitor可以順利的執行相應對象的方法

// 正常邏輯實現

        Service service1 = new Saving();
        Service service2 = new Fund();
        Service service3 = new Draw();
        List<Service> ls = new ArrayList<Service>();
        ls.add(service1);
        ls.add(service2);
        ls.add(service3);
        for (Service service : ls) {
            if (service instanceof Saving) {
                System.out.println("存款");
            } else if (service instanceof Fund) {
                System.out.println("基金");
            } else if (service instanceof Draw) {
                System.out.println("提款");
            }
        }
        //上述的問題是隨着業務量增大 代碼維護量會非常的大 需要不斷的去判斷 
        
        //采用訪問者模式解決
        Service saving = new Saving();
        Service fund = new Fund();
        Service draw = new Draw();
        Visitor visitor = new Visitor();
        saving.accept(visitor);
        fund.accept(visitor);
        draw.accept(visitor);
        //上述中accept中實際上有觀察者的影子 實際上 訪問者我們也可以理解成一個對業務熟悉的觀察者
        //他不斷觀察者是否有新的業務需求 有的話 進行相應的業務處理

小結:

采用Visitor的好處如上面說到的那樣，當需要改變其中一項業務的處理時，不需要每個地方都進行修改，而只需要改動Visitor類中相應的處理函數就可以了。也就是說它適合於業務處理時常發生變動的情況。 

當然，Visitor也有它自身的限制。它不適合於業務數量的經常變化，因為一旦新增或刪除一些Service時，需要對visitor進行相應的增刪。也就是說具體Service與Visitor是耦合的

其實也是將責任抽象成一個個具體的類,從而避免在一個類中既處理邏輯又帶有功能,違反了面向對象原則--責任單一

參考:

http://men4661273.iteye.com/blog/1635167

http://www.cnblogs.com/java-my-life/archive/2012/06/14/2545381.html

---