本文實(shí)例講述了PHP設(shè)計(jì)模式：外觀模式Facade。分享給大家供大家參考，具體如下：

外觀模式，我們通過外觀的包裝，使應(yīng)用程序只能看到外觀對(duì)象，而不會(huì)看到具體的細(xì)節(jié)對(duì)象，這樣無疑會(huì)降低應(yīng)用程序的復(fù)雜度，并且提高了程序的可維護(hù)性。例子1：一個(gè)電源總開關(guān)可以控制四盞燈、一個(gè)風(fēng)扇、一臺(tái)空調(diào)和一臺(tái)電視機(jī)的啟動(dòng)和關(guān)閉。該電源總開關(guān)可以同時(shí)控制上述所有電器設(shè)備，電源總開關(guān)即為該系統(tǒng)的外觀模式設(shè)計(jì)。

為了降低復(fù)雜性，常常將系統(tǒng)劃分為若干個(gè)子系統(tǒng)。但是如何做到各個(gè)系統(tǒng)之間的通信和相互依賴關(guān)系達(dá)到最小呢？

外觀模式：為子系統(tǒng)中的一組接口提供一個(gè)一致的界面， Facade模式定義了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。引入外觀角色之后，用戶只需要直接與外觀角色交互，用戶與子系統(tǒng)之間的復(fù)雜關(guān)系由外觀角色來實(shí)現(xiàn)，從而降低了系統(tǒng)的耦合度。

在遇到以下情況使用facade模式： 1) 當(dāng)你要為一個(gè)復(fù)雜子系統(tǒng)提供一個(gè)簡(jiǎn)單接口時(shí)。子系統(tǒng)往往因?yàn)椴粩嘌莼兊迷絹碓綇?fù)雜。大多數(shù)模式使用時(shí)都會(huì)產(chǎn)生更多更小的類。 這使得子系統(tǒng)更具可重用性，也更容易對(duì)子系統(tǒng)進(jìn)行定制，但這也給那些不需要定制子系統(tǒng)的用戶帶來一些使用上的困難。facade可以提供一個(gè)簡(jiǎn)單的缺省視圖， 這一視圖對(duì)大多數(shù)用戶來說已經(jīng)足夠，而那些需要更多的可定制性的用戶可以越過facade層。 2) 客戶程序與抽象類的實(shí)現(xiàn)部分之間存在著很大的依賴性。引入 facade將這個(gè)子系統(tǒng)與客戶以及其他的子系統(tǒng)分離，可以提高子系統(tǒng)的獨(dú)立性 和可移植性。 3) 當(dāng)你需要構(gòu)建一個(gè)層次結(jié)構(gòu)的子系統(tǒng)時(shí)，使用 facade模式定義子系統(tǒng)中每層的入口點(diǎn)。如果子系統(tǒng)之間是相互依賴的，你可以讓它們僅通過facade進(jìn)行通訊，從而簡(jiǎn)化了它們之間的依賴關(guān)系。

外觀角色（Facade）：是模式的核心，他被客戶client角色調(diào)用，知道各個(gè)子系統(tǒng)的功能。同時(shí)根據(jù)客戶角色已有的需求預(yù)訂了幾種功能組合子系統(tǒng)角色（Subsystem classes）：實(shí)現(xiàn)子系統(tǒng)的功能，并處理由Facade對(duì)象指派的任務(wù)。對(duì)子系統(tǒng)而言，facade和client角色是未知的，沒有Facade的任何相關(guān)信息；即沒有指向Facade的實(shí)例。客戶角色（client）：調(diào)用facade角色獲得完成相應(yīng)的功能。

Facade模式有下面一些優(yōu)點(diǎn)：

1）對(duì)客戶屏蔽子系統(tǒng)組件，減少了客戶處理的對(duì)象數(shù)目并使得子系統(tǒng)使用起來更加容易。通過引入外觀模式，客戶代碼將變得很簡(jiǎn)單，與之關(guān)聯(lián)的對(duì)象也很少。2）實(shí)現(xiàn)了子系統(tǒng)與客戶之間的松耦合關(guān)系，這使得子系統(tǒng)的組件變化不會(huì)影響到調(diào)用它的客戶類，只需要調(diào)整外觀類即可。 3）降低了大型軟件系統(tǒng)中的編譯依賴性，并簡(jiǎn)化了系統(tǒng)在不同平臺(tái)之間的移植過程，因?yàn)榫幾g一個(gè)子系統(tǒng)一般不需要編譯所有其他的子系統(tǒng)。一個(gè)子系統(tǒng)的修改對(duì)其他子系統(tǒng)沒有任何影響，而且子系統(tǒng)內(nèi)部變化也不會(huì)影響到外觀對(duì)象。 4）只是提供了一個(gè)訪問子系統(tǒng)的統(tǒng)一入口，并不影響用戶直接使用子系統(tǒng)類。 Facade模式的缺點(diǎn) 1） 不能很好地限制客戶使用子系統(tǒng)類，如果對(duì)客戶訪問子系統(tǒng)類做太多的限制則減少了可變性和靈活性。 2） 在不引入抽象外觀類的情況下，增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”。

我們使用開關(guān)的例子;

<?php /** * 外觀模式 * */ class SwitchFacade{private $_light = null; //電燈private $_ac = null;//空調(diào)private $_fan = null;//電扇private $_tv = null;//電視public function __construct(){$this->_light = new Light();$this->_fan = new Fan();$this->_ac = new AirConditioner();$this->_tv = new Television();}/** * 晚上開電燈 * */public function method1($isOpen =1) {if ($isOpen == 1) {$this->_light->on();$this->_fan->on();$this->_ac->on();$this->_tv->on();}else{$this->_light->off();$this->_fan->off();$this->_ac->off();$this->_tv->off();} }/** * 白天不需要電燈 * */public function method2() {if ($isOpen == 1) {$this->_fan->on();$this->_ac->on();$this->_tv->on();}else{$this->_fan->off();$this->_ac->off();$this->_tv->off();}}} /******************************************子系統(tǒng)類 ************//** * */ class Light{private $_isOpen = 0;public function on() {echo ’Light is open’, ’<br/>’;$this->_isOpen = 1; }public function off() {echo ’Light is off’, ’<br/>’;$this->_isOpen = 0;}} class Fan{private $_isOpen = 0;public function on() {echo ’Fan is open’, ’<br/>’;$this->_isOpen = 1; }public function off() {echo ’Fan is off’, ’<br/>’;$this->_isOpen = 0;}} class AirConditioner{private $_isOpen = 0;public function on() {echo ’AirConditioner is open’, ’<br/>’;$this->_isOpen = 1; }public function off() {echo ’AirConditioner is off’, ’<br/>’;$this->_isOpen = 0;}}class Television{private $_isOpen = 0;public function on() {echo ’Television is open’, ’<br/>’;$this->_isOpen = 1; }public function off() {echo ’Television is off’, ’<br/>’;$this->_isOpen = 0;}}/** * 客戶類 * */class client {static function open() {$f = new SwitchFacade();$f->method1(1);} static function close() {$f = new SwitchFacade();$f->method1(0);}}client::open();11. 與其他相關(guān)模式

1）抽象工廠模式：Abstract Factory式可以與Facade模式一起使用以提供一個(gè)接口，這一接口可用來以一種子系統(tǒng)獨(dú)立的方式創(chuàng)建子系統(tǒng)對(duì)象。 Abstract Factory也可以代替Facade模式隱藏那些與平臺(tái)相關(guān)的類。 2）中介模式：Mediator模式與Facade模式的相似之處是，它抽象了一些已有的類的功能。然而，Mediator的目的是對(duì)同事之間的任意通訊進(jìn)行抽象，通常集中不屬于任何單個(gè)對(duì)象的功能。 Mediator的同事對(duì)象知道中介者并與它通信，而不是直接與其他同類對(duì)象通信。相對(duì)而言，F(xiàn)acade模式僅對(duì)子系統(tǒng)對(duì)象的接口進(jìn)行抽象，從而使它們更容易使用；它并不定義新功能，子系統(tǒng)也不知道Facade的存在。 通常來講，僅需要一個(gè)Facade對(duì)象，因此Facade對(duì)象通常屬于Singleton模式。 3）Adapter模式： 適配器模式是將一個(gè)接口通過適配來間接轉(zhuǎn)換為另一個(gè)接口。 外觀模式的話，其主要是提供一個(gè)整潔的一致的接口給客戶端。

1）根據(jù)“單一職責(zé)原則”，在軟件中將一個(gè)系統(tǒng)劃分為若干個(gè)子系統(tǒng)有利于降低整個(gè)系統(tǒng)的復(fù)雜性，一個(gè)常見的設(shè)計(jì)目標(biāo)是使子系統(tǒng)間的通信和相互依賴關(guān)系達(dá)到最小，而達(dá)到該目標(biāo)的途徑之一就是引入一個(gè)外觀對(duì)象，它為子系統(tǒng)的訪問提供了一個(gè)簡(jiǎn)單而單一的入口。

2）外觀模式也是“迪米特法則”的體現(xiàn)，通過引入一個(gè)新的外觀類可以降低原有系統(tǒng)的復(fù)雜度，外觀類充當(dāng)了客戶類與子系統(tǒng)類之間的“第三者”，同時(shí)降低客戶類與子系統(tǒng)類的耦合度。外觀模式就是實(shí)現(xiàn)代碼重構(gòu)以便達(dá)到“迪米特法則”要求的一個(gè)強(qiáng)有力的武器。

3）外觀模式要求一個(gè)子系統(tǒng)的外部與其內(nèi)部的通信通過一個(gè)統(tǒng)一的外觀對(duì)象進(jìn)行，外觀類將客戶端與子系統(tǒng)的內(nèi)部復(fù)雜性分隔開，使得客戶端只需要與外觀對(duì)象打交道，而不需要與子系統(tǒng)內(nèi)部的很多對(duì)象打交道。 4）外觀模式從很大程度上提高了客戶端使用的便捷性，使得客戶端無須關(guān)心子系統(tǒng)的工作細(xì)節(jié)，通過外觀角色即可調(diào)用相關(guān)功能。 5）不要試圖通過外觀類為子系統(tǒng)增加新行為 ，不要通過繼承一個(gè)外觀類在子系統(tǒng)中加入新的行為，這種做法是錯(cuò)誤的。外觀模式的用意是為子系統(tǒng)提供一個(gè)集中化和簡(jiǎn)化的溝通渠道，而不是向子系統(tǒng)加入新的行為，新的行為的增加應(yīng)該通過修改原有子系統(tǒng)類或增加新的子系統(tǒng)類來實(shí)現(xiàn)，不能通過外觀類來實(shí)現(xiàn)。

一個(gè)系統(tǒng)有多個(gè)外觀類： 在外觀模式中，通常只需要一個(gè)外觀類，并且此外觀類只有一個(gè)實(shí)例，換言之它是一個(gè)單例類。在很多情況下為了節(jié)約系統(tǒng)資源，一般將外觀類設(shè)計(jì)為單例類。當(dāng)然這并不意味著在整個(gè)系統(tǒng)里只能有一個(gè)外觀類，在一個(gè)系統(tǒng)中可以設(shè)計(jì)多個(gè)外觀類，每個(gè)外觀類都負(fù)責(zé)和一些特定的子系統(tǒng)交互，向用戶提供相應(yīng)的業(yè)務(wù)功能。 不要試圖通過外觀類為子系統(tǒng)增加新行為：不要通過繼承一個(gè)外觀類在子系統(tǒng)中加入新的行為，這種做法是錯(cuò)誤的。外觀模式的用意是為子系統(tǒng)提供一個(gè)集中化和簡(jiǎn)化的溝通渠道，而不是向子系統(tǒng)加入新的行為，新的行為的增加應(yīng)該通過修改原有子系統(tǒng)類或增加新的子系統(tǒng)類來實(shí)現(xiàn)，不能通過外觀類來實(shí)現(xiàn)。 外觀模式與迪米特法則：外觀模式創(chuàng)造出一個(gè)外觀對(duì)象，將客戶端所涉及的屬于一個(gè)子系統(tǒng)的協(xié)作伙伴的數(shù)量減到最少，使得客戶端與子系統(tǒng)內(nèi)部的對(duì)象的相互作用被外觀對(duì)象所取代。外觀類充當(dāng)了客戶類與子系統(tǒng)類之間的“第三者”，降低了客戶類與子系統(tǒng)類之間的耦合度，外觀模式就是實(shí)現(xiàn)代碼重構(gòu)以便達(dá)到“迪米特法則”要求的一個(gè)強(qiáng)有力的武器。 抽象外觀類的引入： 外觀模式最大的缺點(diǎn)在于違背了“開閉原則”，當(dāng)增加新的子系統(tǒng)或者移除子系統(tǒng)時(shí)需要修改外觀類，可以通過引入抽象外觀類在一定程度上解決該問題，客戶端針對(duì)抽象外觀類進(jìn)行編程。對(duì)于新的業(yè)務(wù)需求，不修改原有外觀類，而對(duì)應(yīng)增加一個(gè)新的具體外觀類，由新的具體外觀類來關(guān)聯(lián)新的子系統(tǒng)對(duì)象，同時(shí)通過修改配置文件來達(dá)到不修改源代碼并更換外觀類的目的。

UML:

更多關(guān)于PHP相關(guān)內(nèi)容感興趣的讀者可查看本站專題：《php面向?qū)ο蟪绦蛟O(shè)計(jì)入門教程》、《PHP數(shù)組(Array)操作技巧大全》、《PHP基本語法入門教程》、《PHP運(yùn)算與運(yùn)算符用法總結(jié)》、《php字符串(string)用法總結(jié)》、《php+mysql數(shù)據(jù)庫(kù)操作入門教程》及《php常見數(shù)據(jù)庫(kù)操作技巧匯總》

希望本文所述對(duì)大家PHP程序設(shè)計(jì)有所幫助。