摘要:定義與類型定義又叫門(mén)面模式,提供了一個(gè)統(tǒng)一的接口,用來(lái)訪問(wèn)子系統(tǒng)中的一群接口外觀模式定義了一個(gè)高層接口,讓子系統(tǒng)更容易使用類型結(jié)構(gòu)型類圖門(mén)面模式是對(duì)系統(tǒng)復(fù)雜的關(guān)系處理做了一個(gè)封裝,對(duì)外提供一個(gè)簡(jiǎn)單的接口,成員介紹子系統(tǒng)被門(mén)面模式封裝的子系統(tǒng)
0x01.定義與類型
定義:又叫門(mén)面模式,提供了一個(gè)統(tǒng)一的接口,用來(lái)訪問(wèn)子系統(tǒng)中的一群接口
外觀模式定義了一個(gè)高層接口,讓子系統(tǒng)更容易使用
類型:結(jié)構(gòu)型
UML類圖
門(mén)面模式是對(duì)系統(tǒng)復(fù)雜的關(guān)系處理做了一個(gè)封裝,對(duì)外提供一個(gè)簡(jiǎn)單的接口,成員介紹:
子系統(tǒng):被門(mén)面模式封裝的子系統(tǒng),也是具體業(yè)務(wù)邏輯的細(xì)節(jié)
facade類:門(mén)面類,對(duì)子系統(tǒng)執(zhí)行流程進(jìn)行封裝,對(duì)外開(kāi)放功能接口,一般為單例對(duì)象。
0x02.適用場(chǎng)景子系統(tǒng)越來(lái)越復(fù)雜,增加外觀模式提供簡(jiǎn)單調(diào)用接口
構(gòu)建多層系統(tǒng)結(jié)構(gòu),利用外觀對(duì)象作為每層的入口,簡(jiǎn)化層間調(diào)用
0x03.優(yōu)點(diǎn)簡(jiǎn)化了調(diào)用過(guò)程,無(wú)需了解深入子系統(tǒng),防止帶來(lái)風(fēng)險(xiǎn)
減少系統(tǒng)依賴、松散耦合
更好的劃分訪問(wèn)層次
符合迪米特法則,即最少知道原則
0x04.缺點(diǎn)增加子系統(tǒng),需要修改門(mén)面類,容易引入風(fēng)險(xiǎn)。
修改門(mén)面類,不符合開(kāi)閉原則
0x05.樣例代碼場(chǎng)景:假設(shè)積分兌換物品流程,一共有三部分別依賴三個(gè)子系統(tǒng)
1.積分校驗(yàn)系統(tǒng),查看是否有資格。
2.積分支付系統(tǒng),兌換禮物,扣減積分等。
3.物流系統(tǒng),兌換禮物后,進(jìn)行配送流程。
如果不適用門(mén)面模式,需要在客戶端進(jìn)行三個(gè)步驟的調(diào)用,而門(mén)面封裝后只需要使用門(mén)面類,下面具體代碼實(shí)現(xiàn):
/** * 禮物實(shí)體類 */ public class PointsGift { private String name; public PointsGift(String name) { this.name = name; } public String getName() { return name; } public void setName(String name) { this.name = name; } } /** * 支付子系統(tǒng) */ public class PointsPaymentService { public boolean pay(PointsGift pointsGift) { //扣減積分 System.out.println("支付:" + pointsGift.getName() + " 積分成功!"); return true; } } /** * 積分校驗(yàn)子系統(tǒng) */ public class QualifyService { public boolean isAvailable (PointsGift pointsGift) { System.out.println("校驗(yàn)" + pointsGift.getName() + "積分資格通過(guò),庫(kù)存通過(guò)"); return true; } } /** * 物流子系統(tǒng) */ public class ShippingService { public String shipGift (PointsGift pointsGift) { //物流系統(tǒng)的對(duì)接邏輯 System.out.println(pointsGift.getName() + "進(jìn)入物流系統(tǒng)"); return "666"; } } /** * 扣減積分門(mén)面類 */ public class GiftExchangeService { /** * 模擬注入 */ private QualifyService qualifyService = new QualifyService(); private PointsPaymentService pointsPaymentService = new PointsPaymentService(); private ShippingService shippingService = new ShippingService(); //模擬注入,一開(kāi)始就已經(jīng)有了三個(gè)依賴的子系統(tǒng) // public void setQualifyService(QualifyService qualifyService) { // this.qualifyService = qualifyService; // } // // public void setPointsPaymentService(PointsPaymentService pointsPaymentService) { // this.pointsPaymentService = pointsPaymentService; // } // // public void setShippingService(ShippingService shippingService) { // this.shippingService = shippingService; // } public void giftExchange (PointsGift pointsGift) { if (qualifyService.isAvailable(pointsGift)) { //資格校驗(yàn)通過(guò) if (pointsPaymentService.pay(pointsGift)) { //如果支付積分成功 String shippingOrderNo = shippingService.shipGift(pointsGift); System.out.println("物流訂單號(hào):" + shippingOrderNo); } } } }
測(cè)試與調(diào)用類
/** * 客戶端與測(cè)試類 */ public class Test { public static void main(String[] args) { PointsGift pointsGift = new PointsGift("連衣裙"); GiftExchangeService giftExchangeService = new GiftExchangeService(); // giftExchangeService.setQualifyService(new QualifyService()); // giftExchangeService.setPointsPaymentService(new PointsPaymentService()); // giftExchangeService.setShippingService(new ShippingService()); giftExchangeService.giftExchange(pointsGift); } }
測(cè)試輸出結(jié)果:
校驗(yàn)連衣裙積分資格通過(guò),庫(kù)存通過(guò) 支付:連衣裙 積分成功! 連衣裙進(jìn)入物流系統(tǒng) 物流訂單號(hào):666
樣例UML
0x06.相關(guān)的設(shè)計(jì)模式
外觀模式和中介者模式
外觀模式關(guān)注的是外界和子系統(tǒng)直接的交互
中介者模式關(guān)注的是子系統(tǒng)之間的交互
外觀模式和單例模式
外觀模式中外觀對(duì)象可以做成單例對(duì)象來(lái)使用
外觀模式和抽象工廠模式
外觀類可以通過(guò)抽象工廠獲取子系統(tǒng)實(shí)例
子系統(tǒng)可以在內(nèi)部對(duì)外觀類進(jìn)行屏蔽
0x07.源碼中的外觀模式SpringJDBC中的:JdbcUtils是對(duì)JDBC的封裝
MyBatis: Configuration中new開(kāi)頭的方法
Tomcat: RequestFacade類
Tomcat: Request類
Tomcat: ResponseFacade類
Tomcat: StandardSessionFacade類
0x08.代碼地址門(mén)面模式: https://github.com/sigmako/design-pattern/tree/master/facade
0x09.參考慕課網(wǎng)設(shè)計(jì)模式精講: https://coding.imooc.com/class/270.html
門(mén)面模式: https://www.cnblogs.com/skywang/articles/1375447.html
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://m.hztianpu.com/yun/75321.html
摘要:門(mén)面模式提供一個(gè)高層次的接口,使得子系統(tǒng)更易于使用。適配器模式和門(mén)面模式區(qū)別適配器模式和門(mén)面模式區(qū)別適配器模式主要做接口轉(zhuǎn)換,解決的是原接口和目標(biāo)接口不匹配的問(wèn)題。1、什么是門(mén)面模式?Provide a unified interface to a set of interfaces in a subsystem.Facade defines a higher-level interface...
摘要:適配器模式不應(yīng)在設(shè)計(jì)階段考慮,它是為了解決已經(jīng)上線的問(wèn)題的存在。組合模式將對(duì)象組合成樹(shù)形結(jié)構(gòu)以表示部分整體的層次結(jié)構(gòu),使得用戶對(duì)單個(gè)對(duì)象和組合對(duì)象的使用具有一致性。 代理模式 代理模式之前已經(jīng)講過(guò),附上鏈接代理模式 裝飾者模式 裝飾者模式定義:動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)。就增加功能來(lái)說(shuō),裝飾模式相比生成子類更為靈活。 裝飾模式博主在第一次學(xué)習(xí)是懵逼的,是因?yàn)榇砟J街写韺?duì)象和...
摘要:本回內(nèi)容介紹上一回聊到工廠模式,略抽象。官方說(shuō)法,門(mén)面模式是指提供一個(gè)統(tǒng)一的接口去訪問(wèn)多個(gè)子系統(tǒng)的多個(gè)不同的接口,為子系統(tǒng)中的一組接口提供一個(gè)統(tǒng)一的高層接口。使得子系統(tǒng)更容易使用。 本回內(nèi)容介紹 上一回聊到工廠模式,略抽象。介一回,咱聊門(mén)面模式就比較容易了,門(mén)面模式也叫外觀模式(facade)。官方說(shuō)法,門(mén)面模式是指提供一個(gè)統(tǒng)一的接口去訪問(wèn)多個(gè)子系統(tǒng)的多個(gè)不同的接口,為子系統(tǒng)中的一組接...
摘要:能夠協(xié)調(diào)調(diào)用者和被調(diào)用者,能夠在一定程度上降低系統(tǒng)的耦合性。特點(diǎn)低耦合性,獨(dú)立性好,安全性應(yīng)用客戶訪問(wèn)不到或者被訪問(wèn)者希望隱藏自己,所以通過(guò)代理來(lái)訪問(wèn)自己。 我們接著上面的幾種模式繼續(xù)講: 4、組合模式 將對(duì)象組合成樹(shù)形結(jié)構(gòu)表示部分-整體的層次結(jié)構(gòu)。 特點(diǎn):靈活性強(qiáng) 應(yīng)用:對(duì)象的部分-整體的層次結(jié)構(gòu),模糊組合對(duì)象和簡(jiǎn)單對(duì)象處理問(wèn)題 代碼實(shí)現(xiàn) /** 組合模式* *///繼承模式clas...
摘要:簡(jiǎn)單的門(mén)面模式實(shí)例事件綁定函數(shù)門(mén)面模式的作用是將復(fù)雜的接口進(jìn)行包裝,變成一個(gè)便于使用的接口。還是以事件相關(guān)為例,事件綁定中還有兩個(gè)常用的分別是和。 門(mén)面模式是什么,與其我去用笨拙的語(yǔ)言去解釋,不如看下面這張圖,曾經(jīng)在網(wǎng)上很火的一張圖片,說(shuō)的是一位兒子為他的爸媽設(shè)置的電腦桌面。 showImg(http://segmentfault.com/img/bVcgHm); 有了這些起好名字...
閱讀 3043·2023-04-26 01:32
閱讀 1639·2021-09-13 10:37
閱讀 2377·2019-08-30 15:56
閱讀 1759·2019-08-30 14:00
閱讀 3194·2019-08-30 12:44
閱讀 2031·2019-08-26 12:20
閱讀 1259·2019-08-23 16:29
閱讀 3308·2019-08-23 14:44