23種設計模式第十六篇：java訪問者模式

定義：封裝某些作用于某種數(shù)據(jù)結(jié)構(gòu)中各元素的操作，它可以在不改變數(shù)據(jù)結(jié)構(gòu)的前提下定義作用于這些元素的新的操作。

類型：行為類模式

類圖：

訪問者模式可能是行為類模式中最復雜的一種模式了，但是這不能成為我們不去掌握它的理由。

我們首先來看一個簡單的例子，代碼如下

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的區(qū)別在哪里，方法method1很簡單，就是打印出一句“我是A”；方法method2稍微復雜一點，使用類B作為參數(shù)，并調(diào)用類B的showA方法。

再來看一下類B的showA方法，showA方法使用類A作為參數(shù)，然后調(diào)用類A的method1方法，可以看到，method2方法繞來繞去，無非就是調(diào)用了一下自己的method1方法而已，它的運行結(jié)果應該也是“我是A”，分析完之后，我們來運行一下這兩個方法，并看一下運行結(jié)果：

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

運行結(jié)果為：

我是A
我是A

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

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

訪問者模式的通用代碼實現(xiàn)

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

訪問者模式的優(yōu)點

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

訪問者模式的適用場景

       假如一個對象中存在著一些與本對象不相干（或者關(guān)系較弱）的操作，為了避免這些操作污染這個對象，則可以使用訪問者模式來把這些操作封裝到訪問者中去。
       假如一組對象中，存在著相似的操作，為了避免出現(xiàn)大量重復的代碼，也可以將這些重復的操作封裝到訪問者中去。
       但是，訪問者模式并不是那么完美，它也有著致命的缺陷：增加新的元素類比較困難。通過訪問者模式的代碼可以看到，在訪問者類中，每一個元素類都有它對應的處理方法，也就是說，每增加一個元素類都需要修改訪問者類（也包括訪問者類的子類或者實現(xiàn)類），修改起來相當麻煩。也就是說，在元素類數(shù)目不確定的情況下，應該慎用訪問者模式。所以，訪問者模式比較適用于對已有功能的重構(gòu)，比如說，一個項目的基本功能已經(jīng)確定下來，元素類的數(shù)據(jù)已經(jīng)基本確定下來不會變了，會變的只是這些元素內(nèi)的相關(guān)操作，這時候，我們可以使用訪問者模式對原有的代碼進行重構(gòu)一遍，這樣一來，就可以在不修改各個元素類的情況下，對原有功能進行修改。

總結(jié)

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

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論