一、

1、使用背景：降低訪問復(fù)雜系統(tǒng)的內(nèi)部子系統(tǒng)時(shí)的復(fù)雜度，簡化客戶端之間的接口。

2、定義：

為子系統(tǒng)中的一組接口定義一個(gè)一致的界面，此模式定義了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。完美地體現(xiàn)了依賴倒轉(zhuǎn)原則和迪米特法則的思想。

3、結(jié)構(gòu)圖：

?4、代碼：

// 子系統(tǒng)接口
interface SubsystemA {
void operationA();
}

interface SubsystemB {
void operationB();
}

// 子系統(tǒng)實(shí)現(xiàn)
class ConcreteSubsystemA implements SubsystemA {
public void operationA() {
System.out.println("SubsystemA operation");
}
}

class ConcreteSubsystemB implements SubsystemB {
public void operationB() {
System.out.println("SubsystemB operation");
}
}

// 外觀類
class Facade

{
private SubsystemA subsystemA;
private SubsystemB subsystemB;

public Facade() {
subsystemA = new ConcreteSubsystemA();
subsystemB = new ConcreteSubsystemB();
}

public void operation() {
subsystemA.operationA();
subsystemB.operationB();
}
}

// 客戶端代碼
public class Client {
public static void main(String[] args) {
Facade facade = new Facade();
facade.operation();
}
}

5、優(yōu)缺點(diǎn)：

?（1）優(yōu)點(diǎn)：

• 減少系統(tǒng)相互依賴。
• 提高靈活性。
• 提高了安全性。

?（2）缺點(diǎn)：

? ? ? 不符合開閉原則，如果要改東西很麻煩，繼承重寫都不合適；

? ? ?不能很好地限制客戶使用子系統(tǒng)類，如果對(duì)客戶訪問子系統(tǒng)類做太多的限制則減少了可變性和? 靈活性；

? ? ?在不引入抽象外觀類的情況下，增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”。

二、與其他設(shè)計(jì)模式的聯(lián)系：

• 外觀模式為現(xiàn)有對(duì)象定義了一個(gè)新接口， 適配器模式則會(huì)試圖運(yùn)用已有的接口。 適配器通常只封裝一個(gè)對(duì)象， 外觀通常會(huì)作用于整個(gè)對(duì)象子系統(tǒng)上。

• 當(dāng)只需對(duì)客戶端代碼隱藏子系統(tǒng)創(chuàng)建對(duì)象的方式時(shí)， 你可以使用抽象工廠模式來代替外觀。

• 享元模式展示了如何生成大量的小型對(duì)象， 外觀則展示了如何用一個(gè)對(duì)象來代表整個(gè)子系統(tǒng)。

• 外觀和中介者模式的職責(zé)類似： 它們都嘗試在大量緊密耦合的類中組織起合作。

  • 外觀為子系統(tǒng)中的所有對(duì)象定義了一個(gè)簡單接口， 但是它不提供任何新功能。 子系統(tǒng)本身不會(huì)意識(shí)到外觀的存在。 子系統(tǒng)中的對(duì)象可以直接進(jìn)行交流。
  • 中介者將系統(tǒng)中組件的溝通行為中心化。 各組件只知道中介者對(duì)象， 無法直接相互交流。

• 外觀類通?？梢赞D(zhuǎn)換為單例模式類， 因?yàn)樵诖蟛糠智闆r下一個(gè)外觀對(duì)象就足夠了。

• 外觀與代理模式的相似之處在于它們都緩存了一個(gè)復(fù)雜實(shí)體并自行對(duì)其進(jìn)行初始化。 代理與其服務(wù)對(duì)象遵循同一接口， 使得自己和服務(wù)對(duì)象可以互換， 在這一點(diǎn)上它與外觀不同。

?三、使用場(chǎng)景：對(duì)于復(fù)雜難以維護(hù)的老系統(tǒng)，可以為新系統(tǒng)開發(fā)一個(gè)外觀 Facade類，來提供設(shè)計(jì)粗糙或高度復(fù)雜的遺留代碼的比較清晰簡單的接口，讓新系統(tǒng)與Facade對(duì)象交互，F(xiàn)acade與遺留代碼交互所有復(fù)雜的工作。實(shí)現(xiàn)方法：文章來源地址http://www.zghlxwxcb.cn/news/detail-665521.html

1. 考慮能否在現(xiàn)有子系統(tǒng)的基礎(chǔ)上提供一個(gè)更簡單的接口。 如果該接口能讓客戶端代碼獨(dú)立于眾多子系統(tǒng)類， 那么你的方向就是正確的。
2. 在一個(gè)新的外觀類中聲明并實(shí)現(xiàn)該接口。 外觀應(yīng)將客戶端代碼的調(diào)用重定向到子系統(tǒng)中的相應(yīng)對(duì)象處。 如果客戶端代碼沒有對(duì)子系統(tǒng)進(jìn)行初始化， 也沒有對(duì)其后續(xù)生命周期進(jìn)行管理， 那么外觀必須完成此類工作。
3. 如果要充分發(fā)揮這一模式的優(yōu)勢(shì)， 你必須確保所有客戶端代碼僅通過外觀來與子系統(tǒng)進(jìn)行交互。 此后客戶端代碼將不會(huì)受到任何由子系統(tǒng)代碼修改而造成的影響， 比如子系統(tǒng)升級(jí)后， 你只需修改外觀中的代碼即可。
4. 如果外觀變得過于臃腫， 你可以考慮將其部分行為抽取為一個(gè)新的專用外觀類。

到了這里，關(guān)于設(shè)計(jì)模式（8）外觀模式的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！