DP-访问者模式(Visitor Pattern)
一、?訪問者(Visitor)模式
訪問者模式的目的是封裝一些施加于某種數據結構元素之上的操作。一旦這些操作需要修改的話,接受這個操作的數據結構則可以保持不變。
問題提出
System.Collection命名空間下提供了大量集合操作對象。但大多數情況下處理的都是同類對象的聚集。換言之,在聚集上采取的操作都是一些針對同類型對象的同類操作。但是如果針對一個保存有不同類型對象的聚集采取某種操作該怎么辦呢?
粗看上去,這似乎不是什么難題。可是如果需要針對一個包含不同類型元素的聚集采取某種操作,而操作的細節(jié)根據元素的類型不同而有所不同時,就會出現必須對元素類型做類型判斷的條件轉移語句。這個時候,使用訪問者模式就是一個值得考慮的解決方案。
訪問者模式
訪問者模式適用于數據結構相對未定的系統(tǒng),它把數據結構和作用于結構上的操作之間的耦合解脫開,使得操作集合可以相對自由地演化。
數據結構的每一個節(jié)點都可以接受一個訪問者的調用,此節(jié)點向訪問者對象傳入節(jié)點對象,而訪問者對象則反過來執(zhí)行節(jié)點對象的操作。這樣的過程叫做"雙重分派"。節(jié)點調用訪問者,將它自己傳入,訪問者則將某算法針對此節(jié)點執(zhí)行。
雙重分派意味著施加于節(jié)點之上的操作是基于訪問者和節(jié)點本身的數據類型,而不僅僅是其中的一者。
二、?訪問者模式的結構
如下圖所示,這個靜態(tài)圖顯示了有兩個具體訪問者和兩個具體節(jié)點的訪問者模式的設計,必須指出的是,具體訪問者的數目與具體節(jié)點的數目沒有任何關系,雖然在這個示意性的系統(tǒng)里面兩者的數目都是兩個。
訪問者模式涉及到抽象訪問者角色、具體訪問者角色、抽象節(jié)點角色、具體節(jié)點角色、結構對象角色以及客戶端角色。
- 抽象訪問者(Visitor)角色:聲明了一個或者多個訪問操作,形成所有的具體元素角色必須實現的接口。
- 具體訪問者(ConcreteVisitor)角色:實現抽象訪問者角色所聲明的接口,也就是抽象訪問者所聲明的各個訪問操作。
- 抽象節(jié)點(Node)角色:聲明一個接受操作,接受一個訪問者對象作為一個參量。
- 具體節(jié)點(Node)角色:實現了抽象元素所規(guī)定的接受操作。
- 結構對象(ObiectStructure)角色:有如下的一些責任,可以遍歷結構中的所有元素;如果需要,提供一個高層次的接口讓訪問者對象可以訪問每一個元素;如果需要,可以設計成一個復合對象或者一個聚集,如列(List)或集合(Set)。
三、?示意性源代碼
//?Visitor?pattern?--?Structural?example??using?System;
using?System.Collections;
//?"Visitor"
abstract?class?Visitor
{
??//?Methods
??abstract?public?void?VisitConcreteElementA(
????ConcreteElementA?concreteElementA?);
??abstract?public?void?VisitConcreteElementB(
????ConcreteElementB?concreteElementB?);
}
//?"ConcreteVisitor1"
class?ConcreteVisitor1?:?Visitor
{
??//?Methods
??override?public?void?VisitConcreteElementA(
????ConcreteElementA?concreteElementA?)
??{
????Console.WriteLine(?"{0}?visited?by?{1}",
??????concreteElementA,?this?);
??}
??override?public?void?VisitConcreteElementB(
????ConcreteElementB?concreteElementB?)
??{
????Console.WriteLine(?"{0}?visited?by?{1}",
??????concreteElementB,?this?);
??}
}
//?"ConcreteVisitor2"
class?ConcreteVisitor2?:?Visitor
{
??//?Methods
??override?public?void?VisitConcreteElementA(
????ConcreteElementA?concreteElementA?)
??{
????Console.WriteLine(?"{0}?visited?by?{1}",
??????concreteElementA,?this?);
??}
??override?public?void?VisitConcreteElementB(
????ConcreteElementB?concreteElementB?)
??{
????Console.WriteLine(?"{0}?visited?by?{1}",
??????concreteElementB,?this?);
??}
}
//?"Element"
abstract?class?Element
{
??//?Methods
??abstract?public?void?Accept(?Visitor?visitor?);
}
//?"ConcreteElementA"
class?ConcreteElementA?:?Element
{
??//?Methods
??override?public?void?Accept(?Visitor?visitor?)
??{
????visitor.VisitConcreteElementA(?this?);
??}
??public?void?OperationA()
??{
??}
}
//?"ConcreteElementB"
class?ConcreteElementB?:?Element
{
??//?Methods
??override?public?void?Accept(?Visitor?visitor?)
??{
????visitor.VisitConcreteElementB(?this?);
??}
??public?void?OperationB()
??{
??}
}
//?"ObjectStructure"
class?ObjectStructure
{
??//?Fields
??private?ArrayList?elements?=?new?ArrayList();
??//?Methods
??public?void?Attach(?Element?element?)
??{
????elements.Add(?element?);
??}
??public?void?Detach(?Element?element?)
??{
????elements.Remove(?element?);
??}
??public?void?Accept(?Visitor?visitor?)
??{
????foreach(?Element?e?in?elements?)
??????e.Accept(?visitor?);
??}
}
/**////?<summary>
///?Client?test
///?</summary>
public?class?Client
{
??public?static?void?Main(?string[]?args?)
??{
????//?Setup?structure
????ObjectStructure?o?=?new?ObjectStructure();
????o.Attach(?new?ConcreteElementA()?);
????o.Attach(?new?ConcreteElementB()?);
????//?Create?visitor?objects
????ConcreteVisitor1?v1?=?new?ConcreteVisitor1();
????ConcreteVisitor2?v2?=?new?ConcreteVisitor2();
????//?Structure?accepting?visitors
????o.Accept(?v1?);
????o.Accept(?v2?);
??}
}
結構對象會遍歷它自己所保存的聚集中的所有節(jié)點,在本系統(tǒng)中就是節(jié)點ConcreteElementA和節(jié)點ConcreteElementB。首先ConcreteElementA會被訪問到,這個訪問是由以下的操作組成的:
從而就完成了雙重分派過程,接著,ConcreteElementB會被訪問,這個訪問的過程和ConcreteElementA被訪問的過程是一樣的。
因此,結構對象對聚集元素的遍歷過程就是對聚集中所有的節(jié)點進行委派的過程,也就是雙重分派的過程。換言之,系統(tǒng)有多少個節(jié)點就會發(fā)生多少個雙重分派過程。
四、?一個實際應用Visitor模式的例子
以下的例子演示了Employee對象集合允許被不同的Visitor(IncomeVisitor與VacationVisitor)訪問其中的內容。
//?Visitor?pattern?--?Real?World?example??using?System;
using?System.Collections;
//?"Visitor"
abstract?class?Visitor
{
??//?Methods
??abstract?public?void?Visit(?Element?element?);
}
//?"ConcreteVisitor1"
class?IncomeVisitor?:?Visitor
{
??//?Methods
??public?override?void?Visit(?Element?element?)
??{
????Employee?employee?=?((Employee)element);
?
????//?Provide?10%?pay?raise
????employee.Income?*=?1.10;
????Console.WriteLine(?"{0}'s?new?income:?{1:C}",
??????employee.Name,?employee.Income?);
??}
}
//?"ConcreteVisitor2"
class?VacationVisitor?:?Visitor
{
??public?override?void?Visit(?Element?element?)
??{
????Employee?employee?=?((Employee)element);
????//?Provide?3?extra?vacation?days
????employee.VacationDays?+=?3;
????Console.WriteLine(?"{0}'s?new?vacation?days:?{1}",
??????employee.Name,?employee.VacationDays?);
??}
}
//?"Element"
abstract?class?Element
{
??//?Methods
??abstract?public?void?Accept(?Visitor?visitor?);
}
//?"ConcreteElement"
class?Employee?:?Element
{
??//?Fields
??string?name;
??double?income;
??int?vacationDays;
??//?Constructors
??public?Employee(?string?name,?double?income,
????int?vacationDays?)
??{
????this.name?=?name;
????this.income?=?income;
????this.vacationDays?=?vacationDays;
??}
??//?Properties
??public?string?Name
??{
????get{?return?name;?}
????set{?name?=?value;?}
??}
??public?double?Income
??{
????get{?return?income;?}
????set{?income?=?value;?}
??}
??public?int?VacationDays
??{
????get{?return?vacationDays;?}
????set{?vacationDays?=?value;?}
??}
??//?Methods
??public?override?void?Accept(?Visitor?visitor?)
??{
????visitor.Visit(?this?);
??}
}
//?"ObjectStructure"
class?Employees
{
??//?Fields
??private?ArrayList?employees?=?new?ArrayList();
??//?Methods
??public?void?Attach(?Employee?employee?)
??{
????employees.Add(?employee?);
??}
??public?void?Detach(?Employee?employee?)
??{
????employees.Remove(?employee?);
??}
??public?void?Accept(?Visitor?visitor?)
??{
????foreach(?Employee?e?in?employees?)
??????e.Accept(?visitor?);
??}
}
/**////?<summary>
///?VisitorApp?test
///?</summary>
public?class?VisitorApp
{
??public?static?void?Main(?string[]?args?)
??{
????//?Setup?employee?collection
????Employees?e?=?new?Employees();
????e.Attach(?new?Employee(?"Hank",?25000.0,?14?)?);
????e.Attach(?new?Employee(?"Elly",?35000.0,?16?)?);
????e.Attach(?new?Employee(?"Dick",?45000.0,?21?)?);
????//?Create?two?visitors
????IncomeVisitor?v1?=?new?IncomeVisitor();
????VacationVisitor?v2?=?new?VacationVisitor();
????//?Employees?are?visited
????e.Accept(?v1?);
????e.Accept(?v2?);
??}
}
?
五、?在什么情況下應當使用訪問者模式
有意思的是,在很多情況下不使用設計模式反而會得到一個較好的設計。換言之,每一個設計模式都有其不應當使用的情況。訪問者模式也有其不應當使用的情況,讓我們
先看一看訪問者模式不應當在什么情況下使用。
傾斜的可擴展性
訪問者模式僅應當在被訪問的類結構非常穩(wěn)定的情況下使用。換言之,系統(tǒng)很少出現需要加入新節(jié)點的情況。如果出現需要加入新節(jié)點的情況,那么就必須在每一個訪問對象里加入一個對應于這個新節(jié)點的訪問操作,而這是對一個系統(tǒng)的大規(guī)模修改,因而是違背"開一閉"原則的。
訪問者模式允許在節(jié)點中加入新的方法,相應的僅僅需要在一個新的訪問者類中加入此方法,而不需要在每一個訪問者類中都加入此方法。
顯然,訪問者模式提供了傾斜的可擴展性設計:方法集合的可擴展性和類集合的不可擴展性。換言之,如果系統(tǒng)的數據結構是頻繁變化的,則不適合使用訪問者模式。
"開一閉"原則和對變化的封裝
面向對象的設計原則中最重要的便是所謂的"開一閉"原則。一個軟件系統(tǒng)的設計應當盡量做到對擴展開放,對修改關閉。達到這個原則的途徑就是遵循"對變化的封裝"的原則。這個原則講的是在進行軟件系統(tǒng)的設計時,應當設法找出一個軟件系統(tǒng)中會變化的部分,將之封裝起來。
很多系統(tǒng)可以按照算法和數據結構分開,也就是說一些對象含有算法,而另一些對象含有數據,接受算法的操作。如果這樣的系統(tǒng)有比較穩(wěn)定的數據結構,又有易于變化的算法的話,使用訪問者模式就是比較合適的,因為訪問者模式使得算法操作的增加變得容易。
反過來,如果這樣一個系統(tǒng)的數據結構對象易于變化,經常要有新的數據對象增加進來的話,就不適合使用訪問者模式。因為在訪問者模式中增加新的節(jié)點很困難,要涉及到在抽象訪問者和所有的具體訪問者中增加新的方法。
六、?使用訪問者模式的優(yōu)點和缺點
訪問者模式有如下的優(yōu)點:
訪問者模式有如下的缺點:
轉載于:https://www.cnblogs.com/piwxsz/archive/2007/06/04/770243.html
總結
以上是生活随笔為你收集整理的DP-访问者模式(Visitor Pattern)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 低学历的非要考研,多半输得更惨
- 下一篇: 七之困