詳解PHP中的外觀模式facade pattern

NO IMAGE

關於facade這個詞的翻譯

facade這個詞,原意指的是一個建築物的表面、外觀,在建築學中被翻譯為“立面”這個術語,國內對facade這個詞的關注,可能更多要依賴於laravel的流行,似乎都一致把laravel裡的facade翻譯作“門面”。說實在的,當第一次看到翻譯文件裡提什麼“門面”的時候,我想你跟我的內心一樣:“這是在說什麼玩意呢?你是在講商店、店鋪的門面嗎?”直到現在,如果非得用中文說facade,非得用“門面”這個詞,我的心裡還是不自覺地會“咯噔”那麼一下,我知道這裡是有問題的。

facade到底翻譯作啥好呢?倒是也有的人群乾脆提倡不翻譯,遇到它就直接英文單詞拿過來,這也不是個長遠辦法,終歸是要為了新入門的人鋪平理解的道路才好。後來偶然看到臺灣的學者,確切說是臺灣的維基百科,將facade pattern譯作“外觀模式”,考慮到該模式的實際作用,方才感覺瞬間釋然。即使laravel裡的facade,嚴格上並不是facade pattern,很多人到現在依然在批評laravel在facade這個詞語上的濫用和誤導,但它終歸也是在借用或模仿facade pattern,所以laravel裡的facade,本文也認為同樣翻譯成“外觀”比較好,當然,為了更好理解,可以是“服務外觀”。即使如此,從私人角度,我更希望將其直呼為“服務定位器”、“服務代理”或者“服務別名”,實際上國外的很多人也是建議如此更名,只是Taylor在這件事上態度一反往常地強硬,所以也暫且不必強求。

通過下文,待實際瞭解了facade pattern具體是啥後,我想你會更好地理解為什麼翻譯為“外觀模式”更貼切。

什麼是facade pattern(“外觀模式”的定義)

不論在現實世界還是程式設計世界,facade(外觀)的目的就是給一個可能原本醜的、雜亂的東西,“披上”一個優美的、吸引人的外觀、或者說面具,用中國的俗話就是:什麼是外觀?“人靠衣裝馬靠鞍”。基於此,facade pattern就是將一個或多個雜亂的、複雜的、不容易重構的class,新增上(或轉換成)一個漂亮優雅的對接入口(interface),這樣呢好讓你更樂意、更方便地去操作它,從而間接地操作了背後的實際邏輯。

什麼時候需要用facade pattern

facade pattern(“外觀模式”)經常是用來給一個或多個子系統,來提供統一的入口介面(interface),或者說操作介面。
當你需要操作別人遺留下來的專案,或者說第三方的程式碼的時候。尤其是通常情況下,這些程式碼你不容易去重構它們,也沒有提供測試(tests)。這個時候,你就可以建立一個facade(“外觀”),去將原來的程式碼“包裹”起來,以此來簡化或優化其使用場景。

說得再多,不如來幾個例子直觀:

示例一:在java中,通過facade操作計算機內部複雜的系統資訊

假設我們有這麼一些複雜的子系統邏輯:


class CPU {
public void freeze() { ... }
public void jump(long position) { ... }
public void execute() { ... }
}
class Memory {
public void load(long position, byte[] data) {
...
}
}
class HardDrive {
public byte[] read(long lba, int size) {
...
}
}

為了更方便地操作它們,我們可以來建立一個外觀類(facade):


class Computer {
public void startComputer() {
cpu.freeze();
memory.load(BOOT_ADDRESS, hardDrive.read(BOOT_SECTOR, SECTOR_SIZE));
cpu.jump(BOOT_ADDRESS);
cpu.execute();
}
}

然後我們的客戶,就可以很方便地來這樣呼叫了:


class You {
public static void main(String[] args) {
Computer facade = new Computer();
facade.startComputer();
}
}

示例二:一個糟糕的第三方郵件類

假設你不得不用下面這個看上去很糟糕的第三方郵件類,尤其是裡面每個方法名你都得停留個好幾秒才能看懂:


interface SendMailInterface
{
public function setSendToEmailAddress($emailAddress);
public function setSubjectName($subject);
public function setTheEmailContents($body);
public function setTheHeaders($headers);
public function getTheHeaders();
public function getTheHeadersText();
public function sendTheEmailNow();
}
class SendMail implements SendMailInterface
{
public $to, $subject, $body;
public $headers = array();
public function setSendToEmailAddress($emailAddress)
{
$this->to = $emailAddress;
}
public function setSubjectName($subject)
{
$this->subject = $subject;
}
public function setTheEmailContents($body)
{
$this->body = $body;
}
public function setTheHeaders($headers)
{
$this->headers = $headers;
}
public function getTheHeaders()
{
return $this->headers;
}
public function getTheHeadersText()
{
$headers = "";
foreach ($this->getTheHeaders() as $header) {
$headers .= $header . "\r\n";
}
}
public function sendTheEmailNow()
{
mail($this->to, $this->subject, $this->body, $this->getTheHeadersText());
}
}

這個時候你又不好直接改原始碼,沒辦法,來一個facade吧


class SendMailFacade
{
private $sendMail;
public function __construct(SendMailInterface $sendMail)
{
$this->sendMail = $sendMail;
}
public function setTo($to)
{
$this->sendMail->setSendToEmailAddress($to);
return $this;
}
public function setSubject($subject)
{
$this->sendMail->setSubjectName($subject);
return $this;
}
public function setBody($body)
{
$this->sendMail->setTheEmailContents($body);
return $this;
}
public function setHeaders($headers)
{
$this->sendMail->setTheHeaders($headers);
return $this;
}
public function send()
{
$this->sendMail->sendTheEmailNow();
}
}

然後原來不加優化的終端呼叫可能是這樣的:


$sendMail = new SendMail();
$sendMail->setSendToEmailAddress($to);
$sendMail->setSubjectName($subject);
$sendMail->setTheEmailContents($body);
$sendMail->setTheHeaders($headers);
$sendMail->sendTheEmailNow();

現在有了外觀類,就可以這樣了:


$sendMail  = new SendMail();
$sendMailFacade = new sendMailFacade($sendMail);
$sendMailFacade->setTo($to)->setSubject($subject)->setBody($body)->setHeaders($headers)->send();

示例三:完成一個商品交易的複雜流程

假設呢,一個商品交易環節需要有這麼幾步:


$productID = $_GET['productId']; 
$qtyCheck = new productQty();
// 檢查庫存
if($qtyCheck->checkQty($productID) > 0) {
// 新增商品到購物車
$addToCart = new addToCart($productID);
// 計算運費
$shipping = new shippingCharge();
$shipping->updateCharge();
// 計算打折
$discount = new discount();
$discount->applyDiscount();
$order = new order();
$order->generateOrder();
}

可以看到,一個流程呢包含了很多步驟,涉及到了很多Object,一旦類似環節要用在多個地方,可能就會導致問題,所以可以先建立一個外觀類:


class productOrderFacade {
public $productID = '';  
public function __construct($pID) {
$this->productID = $pID;
}
public function generateOrder() {   
if($this->qtyCheck()) {
$this->addToCart();
$this->calulateShipping();
$this->applyDiscount();
$this->placeOrder();
}   
}
private function addToCart () {
/* .. add product to cart .. */
} 
private function qtyCheck() {
$qty = 'get product quantity from database';
if($qty > 0) {
return true;
} else {
return true;
}
}
private function calulateShipping() {
$shipping = new shippingCharge();
$shipping->calculateCharge();
}
private function applyDiscount() {
$discount = new discount();
$discount->applyDiscount();
}
private function placeOrder() {
$order = new order();
$order->generateOrder();
}
}

這樣呢,我們的終端呼叫就可以兩行解決:


$order = new productOrderFacade($productID);
$order->generateOrder();

示例四:往多個社交媒體同步訊息的流程


// 發Twitter訊息
class CodeTwit {
function tweet($status, $url)
{
var_dump('Tweeted:'.$status.' from:'.$url);
}
}
// 分享到Google plus上
class Googlize {
function share($url)
{
var_dump('Shared on Google plus:'.$url);
}
}
//分享到Reddit上
class Reddiator {
function reddit($url, $title)
{
var_dump('Reddit! url:'.$url.' title:'.$title);
}
}

如果每次我們寫了一篇文章,想著轉發到其他平臺,都得分別去呼叫相應方法,這工作量就太大了,後期平臺數量往往只增不減呢。這個時候藉助於facade class:


class shareFacade {
protected $twitter; 
protected $google; 
protected $reddit; 
function __construct($twitterObj,$gooleObj,$redditObj)
{
$this->twitter = $twitterObj;
$this->google = $gooleObj;
$this->reddit = $redditObj;
} 
function share($url,$title,$status)
{
$this->twitter->tweet($status, $url);
$this->google->share($url);
$this->reddit->reddit($url, $title);
}
}

這樣終端呼叫就可以:


$shareObj = new shareFacade($twitterObj,$gooleObj,$redditObj);
$shareObj->share('//myBlog.com/post-awsome','My greatest post','Read my greatest post ever.');

facade pattern的優劣勢

優勢

能夠使你的終端呼叫與背後的子系統邏輯解耦,這往往發生在你的controller裡,就意味著你的controller可以有更少的依賴,controller關注的更少了,從而責任和邏輯也更明確了,同時也意味著你子系統裡的邏輯更改,並不會影響到你的controller裡終端呼叫。

劣勢

雖然特別有用,但是一個常見的陷阱就是,過度使用這個模式,明明可能那個時候你並不需要,這個往往注意即可。當然也有人爭論說,明明我原來的程式碼都能用,幹嘛費這個勁,那麼同樣是房子,你是喜歡住在精緻的屋子裡呢,還是說有四面牆就行了呢?

感覺facade pattern與其他的設計模式似曾相識?

認真學過我們《Laravel底層核心技術實戰揭祕》這一課程的同學,可能到這裡就會尤其覺得這個facade pattern好像在哪裡見過?可能你會脫口而出:“這貨跟之前咱們學的decorator pattern有啥區別呢?為啥不直接說成修飾者模式呢?”

確實,在“包裝”邏輯方面,它們確實類似,但是:

修飾者模式(Decorator)——用來給一個Object新增、包裹上新的行為、邏輯,而不需要改動原來的程式碼

外觀模式(facade pattern)——用來給一個或多個複雜的子系統、或者第三方庫,提供統一的入口,或者說統一的終端呼叫方式

還是有一定差別的~