(轉)訪問者模式

來源:互聯網
上載者:User

標籤:

原文:http://blog.csdn.net/zhengzhb/article/details/7489639

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

類型:行為類模式

類圖:

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

[java] view plaincopy 
  1. class A {  
  2.     public void method1(){  
  3.         System.out.println("我是A");  
  4.     }  
  5.       
  6.     public void method2(B b){  
  7.         b.showA(this);  
  8.     }  
  9. }  
  10.   
  11. class B {  
  12.     public void showA(A a){  
  13.         a.method1();  
  14.     }  
  15. }  

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

[java] view plaincopy 
  1. public class Test {  
  2.     public static void main(String[] args){  
  3.         A a = new A();  
  4.         a.method1();  
  5.         a.method2(new B());  
  6.     }  
  7. }  

運行結果為:

我是A
我是A

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

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

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

[java] view plaincopy 
  1. abstract class Element {  
  2.     public abstract void accept(IVisitor visitor);  
  3.     public abstract void doSomething();  
  4. }  
  5.   
  6. interface IVisitor {  
  7.     public void visit(ConcreteElement1 el1);  
  8.     public void visit(ConcreteElement2 el2);  
  9. }  
  10.   
  11. class ConcreteElement1 extends Element {  
  12.     public void doSomething(){  
  13.         System.out.println("這是元素1");  
  14.     }  
  15.       
  16.     public void accept(IVisitor visitor) {  
  17.         visitor.visit(this);  
  18.     }  
  19. }  
  20.   
  21. class ConcreteElement2 extends Element {  
  22.     public void doSomething(){  
  23.         System.out.println("這是元素2");  
  24.     }  
  25.       
  26.     public void accept(IVisitor visitor) {  
  27.         visitor.visit(this);  
  28.     }  
  29. }  
  30. class Visitor implements IVisitor {  
  31.   
  32.     public void visit(ConcreteElement1 el1) {  
  33.         el1.doSomething();  
  34.     }  
  35.       
  36.     public void visit(ConcreteElement2 el2) {  
  37.         el2.doSomething();  
  38.     }  
  39. }  
  40.   
  41. class ObjectStruture {  
  42.     public static List<Element> getList(){  
  43.         List<Element> list = new ArrayList<Element>();  
  44.         Random ran = new Random();  
  45.         for(int i=0; i<10; i++){  
  46.             int a = ran.nextInt(100);  
  47.             if(a>50){  
  48.                 list.add(new ConcreteElement1());  
  49.             }else{  
  50.                 list.add(new ConcreteElement2());  
  51.             }  
  52.         }  
  53.         return list;  
  54.     }  
  55. }  
  56.   
  57. public class Client {  
  58.     public static void main(String[] args){  
  59.         List<Element> list = ObjectStruture.getList();  
  60.         for(Element e: list){  
  61.             e.accept(new Visitor());  
  62.         }  
  63.     }  
  64. }  


訪問者模式的優點

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

 訪問者模式的適用情境

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

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

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

 

總結

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

(轉)訪問者模式

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.