詳解Java設計模式編程中的訪問者模式

更新時間：2016年02月15日 09:30:10 作者：卡奴達摩

這篇文章主要介紹了Java設計模式編程中的訪問者模式,訪問者模式的合理利用可以避免項目中出現大量重復的代碼,需要的朋友可以參考下

定義：封裝某些作用于某種數據結構中各元素的操作，它可以在不改變數據結構的前提下定義作用于這些元素的新的操作。
類型：行為類模式
類圖：

201621592623368.jpg (596×407)

例子：
例如，思考一下添加不同類型商品的購物車，當點擊結算的時候，它計算出所有不同商品需付的費用?，F在，計算邏輯即為計算這些不同類型商品的價格?；蛘哒f通過訪問者模式我們把此邏輯轉移到了另外一個類上面。讓我們實現這個訪問者模式的例子。

為了實現訪問者模式，最先需要做的是創(chuàng)建能夠被添加到購物車中代表不同類型商品(itemElement)的類。

ItemElement.java

package com.journaldev.design.visitor;

public interface ItemElement {

 public int accept(ShoppingCartVisitor visitor);
}

注意，accept方法接受訪問者作為參數。當然這兒還有其他的一些方法來指定詳細的商品，但為了簡化，此處沒用過多的考慮細節(jié)，只關注訪問者模式。

現在創(chuàng)建一些不同商品的實體類。

Book.java

package com.journaldev.design.visitor;

public class Book implements ItemElement {

 private int price;
 private String isbnNumber;

 public Book(int cost, String isbn){
 this.price=cost;
 this.isbnNumber=isbn;
 }

 public int getPrice() {
 return price;
 }

 public String getIsbnNumber() {
 return isbnNumber;
 }

 @Override
 public int accept(ShoppingCartVisitor visitor) {
 return visitor.visit(this);
 }

}

Fruit.java

package com.journaldev.design.visitor;

public class Fruit implements ItemElement {

 private int pricePerKg;
 private int weight;
 private String name;

 public Fruit(int priceKg, int wt, String nm){
 this.pricePerKg=priceKg;
 this.weight=wt;
 this.name = nm;
 }

 public int getPricePerKg() {
 return pricePerKg;
 }

 public int getWeight() {
 return weight;
 }

 public String getName(){
 return this.name;
 }

 @Override
 public int accept(ShoppingCartVisitor visitor) {
 return visitor.visit(this);
 }

}

注意，accept()方法的實現是在實體類中，它調用訪問者的visit()方法傳遞當前類對象作為自己的參數。
此處針對不同類型的商品所使用的visit()方法將會在訪問者接口的實體類中被實現。

ShoppingCartVisitor.java

package com.journaldev.design.visitor;

public interface ShoppingCartVisitor {

 int visit(Book book);
 int visit(Fruit fruit);
}

現在將實現訪問者接口以及每種商品自己計算自己費用的邏輯。

ShoppingCartVisitorImpl.java

package com.journaldev.design.visitor;

public class ShoppingCartVisitorImpl implements ShoppingCartVisitor {

 @Override
 public int visit(Book book) {
 int cost=0;
 //apply 5$ discount if book price is greater than 50
 if(book.getPrice() > 50){
  cost = book.getPrice()-5;
 }else cost = book.getPrice();
 System.out.println("Book ISBN::"+book.getIsbnNumber() + " cost ="+cost);
 return cost;
 }

 @Override
 public int visit(Fruit fruit) {
 int cost = fruit.getPricePerKg()*fruit.getWeight();
 System.out.println(fruit.getName() + " cost = "+cost);
 return cost;
 }

}

現在看一看在程序中如何使用它。

ShoppingCartClient.java

package com.journaldev.design.visitor;

public class ShoppingCartClient {

 public static void main(String[] args) {
 ItemElement[] items = new ItemElement[]{new Book(20, "1234"),new Book(100, "5678"),
  new Fruit(10, 2, "Banana"), new Fruit(5, 5, "Apple")};

 int total = calculatePrice(items);
 System.out.println("Total Cost = "+total);
 }

 private static int calculatePrice(ItemElement[] items) {
 ShoppingCartVisitor visitor = new ShoppingCartVisitorImpl();
 int sum=0;
 for(ItemElement item : items){
  sum = sum + item.accept(visitor);
 }
 return sum;
 }

}

當運行上述程序是，我們得到如下輸出。

Book ISBN::1234 cost =20
Book ISBN::5678 cost =95
Banana cost = 20
Apple cost = 25
Total Cost = 160

請注意，此處的實現，好像accept()方法對于所有商品是相同的，但是他也可以不同。例如，如果商品為空它能進行邏輯檢查并不再調用visit()方法。
訪問者模式的優(yōu)點：
符合單一職責原則：凡是適用訪問者模式的場景中，元素類中需要封裝在訪問者中的操作必定是與元素類本身關系不大且是易變的操作，使用訪問者模式一方面符合單一職責原則，另一方面，因為被封裝的操作通常來說都是易變的，所以當發(fā)生變化時，就可以在不改變元素類本身的前提下，實現對變化部分的擴展。
擴展性良好：元素類可以通過接受不同的訪問者來實現對不同操作的擴展。
訪問者模式的適用場景：
       假如一個對象中存在著一些與本對象不相干（或者關系較弱）的操作，為了避免這些操作污染這個對象，則可以使用訪問者模式來把這些操作封裝到訪問者中去。
       假如一組對象中，存在著相似的操作，為了避免出現大量重復的代碼，也可以將這些重復的操作封裝到訪問者中去。
       但是，訪問者模式并不是那么完美，它也有著致命的缺陷：增加新的元素類比較困難。通過訪問者模式的代碼可以看到，在訪問者類中，每一個元素類都有它對應的處理方法，也就是說，每增加一個元素類都需要修改訪問者類（也包括訪問者類的子類或者實現類），修改起來相當麻煩。也就是說，在元素類數目不確定的情況下，應該慎用訪問者模式。所以，訪問者模式比較適用于對已有功能的重構，比如說，一個項目的基本功能已經確定下來，元素類的數據已經基本確定下來不會變了，會變的只是這些元素內的相關操作，這時候，我們可以使用訪問者模式對原有的代碼進行重構一遍，這樣一來，就可以在不修改各個元素類的情況下，對原有功能進行修改。

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