PHP의 파사드 패턴 분석에 대하여

이 글은 주로 PHP의 Facade 패턴에 대한 자세한 사용법과 코드 예시를 소개합니다.

facade라는 단어의 번역에 대해

facade라는 단어는 원래 건물의 표면과 외관을 의미하며 건축에서는 "facade"라는 용어로 번역됩니다. laravel의 인기에 대해 모든 사람들이 만장일치로 laravel의 외관을 "facade"로 번역하는 것 같습니다. 솔직히 처음 번역문에서 "facade"에 대한 언급을 봤을 때 저와 같은 생각을 하셨을 것 같아요. "대체 무슨 소리를 하는 거야? 가게 얘기야, 가게 얘기야?" "지금까지 중국어로 "facade"라는 단어를 사용해야 하거나 "facade"라는 단어를 사용해야 하면 내 마음이 의식적으로 "클릭"하지 않았으며 여기에 문제가 있음을 알고 있습니다.

외관에 가장 적합한 번역은 무엇인가요? 그러나 어떤 사람들은 단순히 번역하지 말라고 주장하며, 접할 때 영어 단어만 사용합니다. 이는 결국 초보자가 이해할 수 있는 길을 열어주는 것입니다. 나중에 우연히 대만 학자들, 정확히는 대만의 위키피디아에서 파사드 패턴을 '외관 패턴'으로 번역하는 것을 보고, 이 패턴의 실제 효과를 생각하면 즉시 안도감을 느꼈습니다. 라라벨의 파사드가 엄밀히 말하면 파사드 패턴이 아님에도 불구하고 라라벨이 파사드라는 단어를 오용하고 오해하는 것에 대해 여전히 많은 사람들이 비난하고 있지만 결국 여전히 파사드 패턴을 차용하거나 모방하고 있으므로 라라벨의 파사드는 이번 글에서 다루도록 하겠습니다. 물론 "외모"로 번역하는 것이 더 낫다고 생각합니다. 물론 이해를 돕기 위해 "서비스 외관"이라고 할 수도 있습니다. 그럼에도 불구하고 개인적인 관점에서는 차라리 "서비스 로케이터", "서비스 에이전트" 또는 "서비스 별칭"이라고 부르고 싶습니다. 실제로 해외에서도 많은 사람들이 이런 식으로 이름을 바꾸라고 제안하지만 이에 대한 테일러의 태도는 다음과 같습니다. 유난히 힘들기 때문에 지금은 억지로 할 필요가 없습니다.

다음을 통해 실제로 파사드 패턴이 무엇인지 이해한 후에는 왜 "파사드 패턴"으로 더 적절하게 번역되는지 더 잘 이해할 수 있을 것이라고 생각합니다.

Facade 패턴이란 무엇입니까("facade 패턴"의 정의)

실제 세계에서든 프로그래밍 세계에서든 Facade(외관)의 목적은 원래 보기 흉하고 지저분할 수 있는 것을 "덮는" 것입니다. 아름답고 매력적인 외모, 혹은 가면을 뜻하는 중국 속담: 외모란 무엇인가? "사람은 옷에 의지하고 말은 안장에 의지한다." 이를 바탕으로 파사드 패턴은 지저분하고 복잡하며 리팩터링이 어려운 하나 이상의 클래스를 아름답고 우아한 인터페이스(인터페이스)로 추가(또는 변환)하여 더 행복하고 편안하게 사용할 수 있도록 하는 것입니다. 작동하기 편리하므로 그 뒤에 있는 실제 논리를 간접적으로 작동할 수 있습니다.

Facade 패턴을 사용하는 경우

facade 패턴("외관 패턴")은 하나 이상의 하위 시스템에 대한 통합 입력 인터페이스(인터페이스) 또는 작업 인터페이스를 제공하는 데 자주 사용됩니다.
다른 사람이 남긴 프로젝트나 타사 코드를 운영해야 할 때. 특히 일반적으로 이러한 코드는 쉽게 리팩터링되지 않으며 테스트도 제공되지 않습니다. 이때 원래 코드를 "래핑"하여 사용 시나리오를 단순화하거나 최적화하는 파사드("모양")를 만들 수 있습니다.

아무리 말하더라도 좀 더 직관적으로 만들기 위해 몇 가지 예를 들어보겠습니다.

예 1: 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) {
  ...
 }
}

더 편리하게 작동하기 위해 외관을 만들 수 있습니다:

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();
 }
}

예 2: 나쁜 타사 이메일 클래스

다음과 같은 끔찍해 보이는 타사 이메일 클래스를 사용해야 한다고 가정해 보세요. 특히 그 안의 모든 메서드 이름을 읽으려면 몇 초 동안 멈춰야 하기 때문입니다. 이해:

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();

예 3: 상품 거래의 복잡한 프로세스 완료

상품 거래 링크에 다음이 필요하다고 가정합니다. 다음 단계는 다음과 같습니다.

$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();
}

프로세스에 여러 단계가 포함되어 있고 많은 개체가 포함되어 있음을 알 수 있습니다. 유사한 링크가 여러 위치에서 사용되면 문제가 발생할 수 있으므로 먼저 모양 클래스를 만들 수 있습니다.

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();

예 4: 메시지를 여러 소셜 미디어에 동기화하는 프로세스

// 发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의 파사드 패턴 분석에 대하여의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!