1. 程式人生 > >23種設計模式之——門面模式

23種設計模式之——門面模式

1.定義

門面模式(Facade Pattern)也叫做外觀模式,是一種比較常用的封裝模式,其定義如下:
Provide a unified interface to a set of interfaces in a subsystem.Facade defines a higher-levelinterface that makes the subsystem easier to use.

要求一個子系統的外部與其內部的通訊必須通過一個統一的物件進行。門面模式提供一個高層次的介面,使得子系統更易於使用。

2.釋義

門面模式注重“統一的物件”,也就是提供一個訪問子系統的介面,除了這個介面不允許有任何訪問子系統的行為發生,其通用類圖:



是的,類圖就這麼簡單,但是它代表的意義可是異常複雜,Subsystem Classes是子系統所有類的簡稱,它可能代表一個類,也可能代表幾十個物件的集合。甭管多少物件,我們把這些物件全部圈入子系統的範疇,其結構如圖:


再簡單地說,門面物件是外界訪問子系統內部的唯一通道,不管子系統內部是多麼雜亂無章,只要有門面物件在,就可以做到“金玉其外,敗絮其中”。我們先明確一下門面模式的角色。

3.通用程式碼

子系統:

public class ClassA {
    public void doSomethingA(){
    //業務邏輯
    }
}
public class ClassB {
    public void doSomethingB(){
    //業務邏輯
    }
}
public class ClassC {
    public void doSomethingC(){
    //業務邏輯
    }
}
門面物件:
public class Facade {
    //被委託的物件
    private ClassA a = new ClassA();
    private ClassB b = new ClassB();
    private ClassC c = new ClassC();
    //提供給外部訪問的方法
    public void methodA(){
        this.a.doSomethingA();
    }
    public void methodB(){
        this.b.doSomethingB();
    }
    public void methodC(){
        this.c.doSomethingC();
    }
}



4.門面模式的優點

● 減少系統的相互依賴想想看,如果我們不使用門面模式,外界訪問直接深入到子系統內部,相互之間是一種強耦合關係,你死我就死,你活我才能活,這樣的強依賴是系統設計所不能接受的,門面模式的出現就很好地解決了該問題,所有的依賴都是對門面物件的依賴,與子系統無關。

● 提高了靈活性

依賴減少了,靈活性自然提高了。不管子系統內部如何變化,只要不影響到門面物件,任你自由活動。

● 提高安全性

想讓你訪問子系統的哪些業務就開通哪些邏輯,不在門面上開通的方法,你休想訪問到。

5.門面模式的缺點

門面模式最大的缺點就是不符合開閉原則,對修改關閉,對擴充套件開放,看看我們那個門面對象吧,它可是重中之重,一旦在系統投產後發現有一個小錯誤,你怎麼解決?完全遵從開閉原則,根本沒辦法解決。繼承?覆寫?都頂不上用,唯一能做的一件事就是修改門面角色的程式碼,這個風險相當大,這就需要大家在設計的時候慎之又慎,多思考幾遍才會有好收獲。

6.使用場景

● 為一個複雜的模組或子系統提供一個供外界訪問的介面

● 子系統相對獨立——外界對子系統的訪問只要黑箱操作即可

比如利息的計算問題,沒有深厚的業務知識和紮實的技術水平是不可能開發出該子系統的,但是對於使用該系統的開發人員來說,他需要做的就是輸入金額以及存期,其他的都不用關心,返回的結果就是利息,這時候,門面模式是非使用不可了。

● 預防低水平人員帶來的風險擴散

比如一個低水平的技術人員參與專案開發,為降低個人程式碼質量對整體專案的影響風險,一般的做法是“畫地為牢”,只能在指定的子系統中開發,然後再提供門面介面進行訪問操作。

7.最佳實踐

門面模式是一個很好的封裝方法,一個子系統比較複雜時,比如演算法或者業務比較復雜,就可以封裝出一個或多個門面出來,專案的結構簡單,而且擴充套件性非常好。還有,對於一個較大專案,為了避免人員帶來的風險,也可以使用門面模式,技術水平比較差的成員,儘量安排獨立的模組,然後把他寫的程式封裝到一個門面裡,儘量讓其他專案成員不用看到這些人的程式碼,看也看不懂,我也遇到過一個“高人”寫的程式碼,private方法、建構函式、常量基本都不用,你要一個public方法,好,一個類裡就一個public方法,所有程式碼都在裡面,然後你就看吧,一大坨程式,看著就能把人逼瘋。使用門面模式後,對門面進行單元測試,約束專案成員的程式碼質量,對專案整體質量的提升也是一個比較好的幫助。