首頁 >後端開發 >php教程 >關於PHP中外觀模式facade pattern的解析

關於PHP中外觀模式facade pattern的解析

不言
不言原創
2018-06-13 14:35:502477瀏覽

這篇文章主要介紹了詳解PHP中的外觀模式facade pattern的詳細用法以及程式碼實例,對此有需求的朋友參考下吧。

關於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)——用来给一个或多个复杂的子系统、或者第三方库,提供统一的入口,或者说统一的终端调用方式

还是有一定差别的~

以上就是本文的全部内容,希望对大家的学习有所帮助,更多相关内容请关注PHP中文网!

相关推荐:

学习laravel的模型事件的几种用法

关于PHP的Laravel框架中使用消息队列queue及异步队列的方法分析

Laravel 5框架的模型和控制器以及视图基础流程的学习

以上是關於PHP中外觀模式facade pattern的解析的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn