相關文章
【設計模式】【一】設計六大原則
【設計模式】【二】單例模式的七種寫法
【設計模式】【三】建造者模式
【設計模式】【四】簡單工廠模式
【設計模式】【五】觀察者模式
【設計模式】【六】代理模式
【設計模式】【七】裝飾模式
【設計模式】【八】外觀模式
【設計模式】【九】模版方法模式
【設計模式】【十】工廠方法模式
【設計模式】【十一】策略模式
【設計模式】【十二】享元模式
【設計模式】【十三】抽象工廠模式
1.外觀模式簡介
外觀模式介紹
當我們開發Android的時候,無論是做SDK還是封裝API,我們大多都會用到外觀模式,它通過一個外觀類使得整個系統的結構只有一個統一的高層接口,這樣能降低用戶的使用成本。
外觀模式定義
爲系統中的一組接口提供一個一致的界面,此模式定義了一個高層接口,這個接口使得子系統更加容易使用。
外觀模式結構圖
- Facade:外觀類,知道哪些子系統類負責處理請求,將客戶端的請求代理給適當的子系統對象。
- Subsystem:子系統類,實現子系統的功能,處理外觀類指派的任務,注意子系統類不含有外觀類的引用。
2.外觀模式的簡單實現
在上一篇設計模式之裝飾模式我們舉了武俠的例子,這一篇我們還舉武俠的例子,首先我們把武俠張無忌當作一個系統,他作爲一個武俠,他本身分爲三個系統分別是招式、內功和經脈。
#子系統類(Subsystem)
我們知道張無忌的三個系統分別是招式、內功和經脈。那我們來創建它們:
/**
* 子系統招式
*/
public class ZhaoShi {
public void TaiJiQuan(){
System.out.print("使用着招式太極拳");
}
public void QiShangQuan(){
System.out.print("使用招式七傷拳");
}
public void ShengHuo(){
System.out.print("使用招式聖火令");
}
}
/**
* 子系統內功
*/
public class NeiGong {
public void JiuYang(){
System.out.print("使用九陽神功");
}
public void QianKun(){
System.out.print("使用乾坤大挪移");
}
}
/**
* 子系統經脈
*/
public class JingMai {
public void jingmai(){
System.out.print("開啓經脈");
}
}
張無忌有很多的武學和內功,怎麼將他們搭配,並對外界隱藏呢,我們接下來看看外觀類:
外觀類(Facade)
這裏的外觀類就是張無忌,他負責將自己的招式、內功和經脈通過不同的情況合理的運用:
/**
* 外觀類張無忌
*/
public class ZhangWuJi {
private JingMai jingMai;
private ZhaoShi zhaoShi;
private NeiGong neiGong;
public ZhangWuJi(){
jingMai=new JingMai();
zhaoShi=new ZhaoShi();
neiGong=new NeiGong();
}
/**
* 使用乾坤大挪移
*/
public void Qiankun(){
jingMai.jingmai();//開啓經脈
neiGong.QianKun();//使用內功乾坤大挪移
}
/**
* 使用七傷拳
*/
public void QiShang(){
jingMai.jingmai(); //開啓經脈
neiGong.JiuYang();//使用內功九陽神功
zhaoShi.QiShangQuan();//使用招式七傷拳
}
}
初始化外觀類的同時將各個子系統類創建好。很明顯張無忌很好的將自身的各個系統搭配好,如果使用七傷拳的話就需要開啓經脈、使用內功九陽神功接下來使用招式七傷拳,如果不開經脈或者使用九陽神功的話那麼七傷拳的威力會大打折扣。
客戶端調用
public class Test {
public static void main(String[] args){
ZhangWuJi zhangWuJi=new ZhangWuJi();
//張無忌使用乾坤大挪移
zhangWuJi.Qiankun();
//張無忌使用七傷拳
zhangWuJi.QiShang();
}
}
當張無忌使用乾坤大挪移或者七傷拳的時候,比武的對手顯然不知道張無忌本身運用了什麼,同時張無忌也不需要去重新計劃使用七傷拳的時候需要怎麼做,他已經早就計劃好了。如果每次使用七傷拳或者乾坤大挪移時都要計劃怎麼做很顯然會增加成本並貽誤戰機。另外張無忌也可以改變自己的內功、招式和經脈,這些都是對比武的對手有所隱藏的。
外觀模式本身就是將子系統的邏輯和交互隱藏起來,爲用戶提供一個高層次的接口,使得系統更加易用,同時也隱藏了具體的實現,這樣即使具體的子系統發生了變化,用戶也不會感知到。
3.外觀模式使用場景
- 構建一個有層次結構的子系統時,使用外觀模式定義子系統中每層的入口點,如果子系統之間是相互依賴的,則可以讓他們通過外觀接口進行通信,減少子系統之間的依賴關係。
- 子系統往往會因爲不斷的重構演化而變得越來越複雜,大多數的模式使用時也會產生很多很小的類,這給外部調用他們的用戶程序帶來了使用的困難,我們可以使用外觀類提供一個簡單的接口,對外隱藏子系統的具體實現並隔離變化。
- 當維護一個遺留的大型系統時,可能這個系統已經非常難以維護和拓展,但因爲它含有重要的功能,新的需求必須依賴於它,則可以使用外觀類,來爲設計粗糙或者複雜的遺留代碼提供一個簡單的接口,讓新系統和外觀類交互,而外觀類負責與遺留的代碼進行交互。