1. 程式人生 > >Java設計模式(十一)訪問者模式 中介者模式

Java設計模式(十一)訪問者模式 中介者模式

(二十一)訪問者模式

對已存在的類進行擴充套件,通常需要增加方法,但是如果需要的行為與現有的物件模型不一致,或者無法修改現有程式碼。在這種情況下,不更改類的層次結構,就無法擴充套件該層次結構的行為。如果運用了訪問者模式,就可以支援開發人員擴充套件該類層次結構的行為。

和直譯器模式一樣,訪問者模式通常是基於合成模式的。

訪問者模式在不改變類層次結構的前提下,對該層次結構進行擴充套件。

interface Visitor{
	public void visit(VisiSubject sub);
}
interface VisiSubject{
	public void accept(Visitor visitor);
	public String getSubject();
}
class MyVisitor implements Visitor{
	public void visit(VisiSubject sub){
		System.out.println("visitor MyVisitor:"+sub.getSubject()+"");
	}
}
class MyVisitor2 implements Visitor{
	public void visit(VisiSubject sub){
		System.out.println("visitor MyVisitor2:"+sub.getSubject()+"");
	}
}
class MyVisiSubject implements VisiSubject{
	public void accept(Visitor visitor) {
		visitor.visit(this);
	}
	public String getSubject() {
		return "MyVisiSubject";
	}
}
class MyVisiSubject2 implements VisiSubject{
	public void accept(Visitor visitor) {
		visitor.visit(this);
	}
	public String getSubject() {
		return "MyVisiSubject2";
	}
}
public class VisitorTest {
	public static void main(String[] args){
		Visitor visitor = new MyVisitor2();
		VisiSubject sub = new MyVisiSubject2();
		sub.accept(visitor);
	}
}

訪問者模式是否是一個好的選擇,取決於系統變化的特徵:如果層次結構穩定,變化的是行為那麼就是一個好的選擇。如果行為穩定,層次結構總是變化,就不是一個好的選擇了。因為你需要更新現有的訪問者類,使得他們可以支援新的節點型別。

與任何模式一樣,訪問者模式不是必須的:如果需要使用該模式,就應該物盡其用。判斷是否使用訪問者模式,最好滿足以下條件:

節點型別的集合是穩定的。

共同發生的變化是為不同的節點新增新的功能。

新功能必須適用於所有節點型別。
小結:

訪問者模式使你可以在不改變類層次結構的前提下,為該結構增加新的行為。該模式的機制包括為訪問者定義一個介面,為層次關係中的所有訪問者增加一個accept()方法。accept()方法使用雙重委派技術,將其呼叫委派給訪問者。類層次結構中的物件可以根據其型別呼叫核實的visit()方法。

(二十二)中介者模式

面對物件開發要求儘可能恰當的分配職責,要求物件能夠獨立的完成自己的任務。觀察者模式通過最小化物件與物件之間的職責互動,從而支援職責的合理分配。當物件間的互動趨向複雜,而每個物件都需要知道其他物件的情況時,提供一個集中地控制權是很有用的。當相關物件的互動邏輯獨立於物件的其他行為時,職責的集中同樣有用。

中介者模式的意圖是定義一個物件,封裝一組物件的互動,從而降低物件間的耦合度,避免了物件間的顯式引用,並且可以獨立地改變物件的行為。

interface Mediator{
	public void createMediator();
	public void workAll();
}
abstract class MUser{
	private Mediator mediator;
	public Mediator getMediator(){
		return mediator;
	}
	public MUser(Mediator mediator){
		this.mediator = mediator;
	}
	public abstract void work();
}
class User1 extends MUser{
	public User1(Mediator m){
		super(m);
	}
	public void work(){
		System.out.println("User1");
	}
}
class User2 extends MUser{
	public User2(Mediator m){
		super(m);
	}
	public void work(){
		System.out.println("User2");
	}
}
class MyMediator implements Mediator{
	private MUser user1;
	private MUser user2;
	public MUser getUser1() {  
        return user1;  
    }  
    public MUser getUser2() {  
        return user2;  
    }  
    @Override  
    public void createMediator() {  
        user1 = new User1(this);  
        user2 = new User2(this);  
    }  
    @Override  
    public void workAll() {  
        user1.work();  
        user2.work();  
    }  
}
public class MediatorTest {
	public static void main(String[] args){
		Mediator m = new MyMediator();
		m.createMediator();
		m.workAll();
	}
}
MUser類統一介面,User1和User2分別是不同的物件,兩者之間有關聯,如果不採用中介者模式,則需要兩者相互持有引用,為了解耦引入中介者模式,Mediator為介面,MyMediator為實現類,持有user1跟user2,這兩個類相互獨立,只需要維持和Mediator之間的聯絡,剩下的由MyMediator維護。

相關推薦

Java設計模式訪問者模式 中介模式

(二十一)訪問者模式 對已存在的類進行擴充套件,通常需要增加方法,但是如果需要的行為與現有的物件模型不一致,或者無法修改現有程式碼。在這種情況下,不更改類的層次結構,就無法擴充套件該層次結構的行為。如果運用了訪問者模式,就可以支援開發人員擴充套件該類層次結構的行為。 和直譯

《大話設計模式Java程式碼示例之抽象工廠模式

抽象工廠模式(Abstract Factory):提供一個建立一系列相關或相互依賴物件的介面,而無需指定它們具體的類。 package abstractfactory; /** * 抽象工廠方法(Abstract Factory) * 使用者實體類 */ p

Java設計模式 享元模式

享元模式介紹 享元模式適用場景 面向物件技術可以很好的解決一些靈活性或可擴充套件性問題,但在很多情況下需要在系統中增加類和物件的個數。當物件數量太多時,將導致物件建立及垃圾回收的代價過高,造成效能下降等問題。享元模式通過共享相同或者相似的細粒度物件解

設計模式——生成器模式

所有 boolean concrete @override ttr stat bsp println 無需 1.描述 將一組復雜對象的構建與他的表示相分離,使同樣的構建過程可以創建不同的表示。 2.模式的使用 ·產品(Product):具體生成器要構造的復雜對象。 ·抽象生

設計模式代理模式Proxy結構型

分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!        

設計模式代理

類結構: 1、抽象服務 public interface Service { public void doLogin(String username,String password); } 2、真實服務 public class RealService implemen

設計模式建造模式

用程式畫一個小人,這在遊戲程式裡非常常見。現在簡單一點,要求是小人要有頭、身體、兩手、兩腳就可以了。 第一版  Pen p = new Pen (Color.Yellow); Graphics gThin = pictureBox1.CreateGraphics();

設計模式—— 狀態模式

一、含義 允許物件在內部狀態改變時改變它的行為,物件看起來好像修改了它的類。也就是說當一個物件有許多狀態的時候,我們可以把每個物件抽離出來作為一個具體的類。 二、要點 1.狀態模式允許一個物件基於內部狀態而擁有不同的行為。 2.通過將每個狀態封裝進一個類,我們把以後需要做的任何改變區

一個故事貫穿設計模式訪問者模式

   這裡記錄的是訪問者模式 。  訪問者模式據說是設計模式中最難的一種,看一看它的例子把。 包結構: 類結構: 測試入口: package com.automannn.design_mode.visitor.test; import com.a

Android設計模式-觀察模式

觀察者模式是一種使用頻率非常高的設計模式,最常用的地方就是訂閱-釋出系統。 這個模式的重要作用就是將觀察者和被觀察者解耦,使他們之間的依賴更小甚至沒有。 定義 定義物件一種一對多的依賴關係,使得每當一個物件改變狀態,則所有依賴於他的物件都會得到通知

設計模式:代理模式

優點:   ① 將代理物件和真實被呼叫的目標物件分離,降低了耦合度,提高了擴充套件性。   ② 保護和增強目標物件。 缺點:   ① 增加了代理類,請求速度變慢,增加系統複雜性。 適用範圍:   ① 安全代理,用來控制真實物件的訪問許可權。   ② 智慧代理,呼叫真實物件時,代理處理另外一些

設計模式裝飾模式Decorator-結構型

裝飾者模式Decorator 在程式開發中,有時候開發人員會使用繼承來擴充套件物件的功能,使用者的需求是多變的,也就造成了使用繼承會造成程式碼的大範圍改動,其實擴充套件物件的功能,採用組合比繼承要好的多,當用戶需要變動時,只要將物件組合發生變化就可以了,不會大

設計模式——訪問者模式

1 測評系統的需求 完成測評系統需求 1) 將觀眾分為男人和女人,對歌手進行測評,當看完某個歌手錶演後,得到他們對該歌手不同的評價(評價 有不同的種類,比如 成功、失敗 等)     2) 傳統方案 2 傳統方式的問題分析 1) 如果系統比較小,

Java基礎入門之基本數據包裝類以及簡單轉換

數據包 intvalue nbsp 1.5 lse false 永遠 ring jdk 一、 基本數據類型包裝類 引用數據類型一般為基本數據類型首字母大寫,除了int 、char,其中int的引用數據類型類Integer,char的引用數據類型為Character 關

Java開發筆記常見的數學函式

前面介紹了Java程式設計的四則運算,雖然提供了基礎的加減乘除符號,但是數學上還有其它運算子號,包括四捨五入用到的約等號≈、求絕對值的“| |”、開平方的“√ ̄”,這些運算子形態各異,而且並非ASCII碼的基本字元,也就意味著它們無法原樣搬到Java來。 為此,Java的設計師封裝了一套

Java自學筆記

構造方法 構造方法,建立物件時候給予物件賦值的一種方式,在new的時候執行。 構造方法格式: 修飾符 + 方法名稱(引數型別和名稱){ …… } 注意,構造方法的名稱必須和類名保持完全一致(大小寫也要統一)

分支管理~策略,git merge 合併禁用ff模式

通常,合併分支時,如果可能,Git會用Fast forward模式,但這種 ff 模式下,刪除分支後,會丟掉分支資訊。 如果要強制禁用 Fast forward 模式,Git就會在merge時生成一個新的commit,這樣,從分支歷史上就可以看出分支資訊。 下面開始實踐:git merge

java基礎筆記多型

概念: 同一個物件,在不同時刻體現出不同的狀態 舉例: 貓是貓。貓是動物 Animal cat1 = new Cat(); 多型前提: 要有繼承關係 要有方法重寫(多型的體現) 要有父類引用指向子類 Animal cat1 = new Ca

Java語言學習:列舉型別和泛型

    Java中一個重要的型別:列舉,它可以用來表示一組取值範圍固定的變數,使用 enum 關鍵字定義列舉型別,其中元素不能重複,通常大寫表示。利用Java的反射機制,可以在執行時分析類,如檢視列舉型別的修飾符、父類和自定義方法等,下面簡單說下。    

Java併發程式設計Java中的原子操作類

一、原子操作類簡介 JDK1.5開始提供了java.util.concurrent.atomic包,其中有一系列用法簡單、效能高效、可以執行緒安全更新變數的原子操作類,目前(JDK1.7)大概有這麼些: 二、原子操作類實現原理 以AtomicInteger為例看下原始碼,其中的兩個