繼續開啟設計模式
今天來聊一下外觀模式
依然跑出來乙個實際的需求來引入外觀模式
也就是說這些步驟如果按照傳統的辦法應該是有各種各樣的類。然後裡面涵蓋了這些操作,我們想要實現這樣的效果就必須要通過客戶端也就是使用者來直接操作這些例項。這樣得到的結果是混亂的,不是我們想看到的。而現在假象一下如果存在這樣乙個類。裡面封裝好了這些步驟,步驟和細節均不會透露給使用者看到。裡面只包含了看電影開始。以及看電影結束的操作。也就是說對使用者而言。使用者只需要操作這個類中的開始和結束方法。呼叫非常清晰。我們把這些封裝內部實現細節,蔽內部子系統的細節,使得呼叫端只需跟這個介面發生呼叫,而無需關心這個子系統的內部細節這種設計模式稱作外觀模式。
首先解決這個問題我們想到的是 必須要有這些例項的類
/**
* @author: 德鑫
* description:
* @date: 2021/01/21
*///***
public class ***player
public void on()
public void off()
public void play()
public void pause()
}
/**
* @author: 德鑫
* description:
* @date: 2021/01/21
*///爆公尺花
public class popcorn
public void on()
public void off()
public void pop()
}
/**
* @author: 德鑫
* description: 投影儀
* @date: 2021/01/20
*/public class projector
public void on()
public void off()
public void focus()
}
/**
* @author: 德鑫
* description:
* @date: 2021/01/20
*///螢幕,餓漢式的單例模式
public class screen
public void up()
public void down()
}
/**
* @author: 德鑫
* description:
* @date: 2021/01/21
*///音響
public class stereo
public void on()
public void off()
public void up()
}
/**
* @author: 德鑫
* description:
* @date: 2021/01/21
*/// 燈光
public class theaterlight
public void on()
public void off()
public void dim()
public void bright()
}
現在這些例項的類都已經具備了,我們現在需要的就是如何提供乙個介面型的類,方便客戶端來操作
這裡就適用了外觀模式的場景了
/**
* @author: 德鑫
* description: 家庭影院外觀模式
* * 定義乙個高層介面。給子系統中的一組介面提供乙個一致的介面。用來訪問子系統中的一群介面
* * 也就是說通過定義乙個一致的介面。用以遮蔽內部子系統的細節,使得呼叫端只需跟這個介面發生呼叫,而無需關心這個子系統的內部細節
* * 1) 外觀模式對外遮蔽了子系統的細節,因此外觀模式降低了客戶端對子系統使用的複雜性
* 2) 外觀模式對客戶端與子系統的耦合關係 - 解耦,讓子系統內部的模組更易維護和擴充套件
* 3) 通過合理的使用外觀模式,可以幫我們更好的劃分訪問的層次
* 4) 當系統需要進行分層設計時,可以考慮使用 facade 模式
* 5) 在維護乙個遺留的大型系統時,可能這個系統已經變得非常難以維護和擴充套件,此時可以考慮為新系統開發乙個 facade類,來提供遺留系統的比較清晰簡單的介面,
* 讓新系統與 facade 類互動,提高復用性
* 6) 不能過多的或者不合理的使用外觀模式,
* 使用外觀模式好,還是直接呼叫模組好。要以讓系統有層次,利於維 護為目的。
* * @date: 2021/01/21
*/public class hometheate***cade
//操作分成 4 步
public void ready()
public void play()
public void pause()
public void end()
}
這裡包含了對於上述實體類物件所涵蓋的各個操作步驟。外觀模式隱藏了內部子系統的實現細節。使用者在操作的時候只需要呼叫該facade物件的ready 即可以表示開始看電影的操作。end 表示觀影結束的操作。
寫乙個客戶端來測試一下
public class client
}
從這個例子很容易理解到對於乙個複雜系統而言。我們使用外觀模式對於處理業務邏輯各個層級呼叫是非常清晰的。對於使用者的操作而言是方便的。而在外觀模式最常用的地方就是mybatis的原始碼。
好啦。外觀模式的一些學習分享就到這裡了。後面分享的是享元模式
設計模式GOF23 外觀模式
外觀模式 facade 是結構性模式的一種,也有人稱它為門面模式。結構型模式的核心作用是從程式的結構上實現低耦合,從而可以擴大整體的類結構,用來解決更大的問題。外觀模式的核心就是為子系統提供統一的入口,封裝系統的複雜性,便於客戶端呼叫。外觀角色 在客戶端可以呼叫它的方法,它會把客戶端呼叫需要的操作放...
GOF23設計模式之外觀模式不使用外觀模式的實現
package com.bjsxt.cn.nofacade public inte ce 工商局 class 海淀區工商局 implements 工商局 package com.bjsxt.cn.nofacade public inte ce 稅務局 class 海淀區稅務局 implements ...
GOF23設計模式之外觀模式(facade)
外觀模式也稱為門面模式。核心 為了系統提供統一的入口,封裝子系統的複雜性,便於客戶端呼叫。場景 要想自己去註冊乙個公司,首先去工商局檢測命名是否合法,再去質量監督局辦理組織機構 證,再去稅務局辦理稅務登記,最後去工商銀行開戶。但是使用外觀模式,只需要去註冊公司的門面,裡邊的工作人員就會去辦理上述證件...