PHP常用的三種設計模式

本文為大家介紹常用的三種php設計模式：單例模式、工廠模式、觀察者模式，有需要的朋友可以參考下。

一、首先來看，單例模式

所謂單例模式，就是確保某個類只有一個實例，而且自行實例化並向整個系統提供這個實例，即在應用程序中只會有這個類的一個實例存在。
通常單例模式用在僅允許數據庫訪問對象的實例中，從而防止打開多個數據庫連接，單例模式是一種常見的設計模式，在計算機系統中，線程池、緩存、日志對象、對話框、打印機、數據庫操作、顯卡的驅動程序常被設計成單例。

一個單例類應包括以下幾點：
和普通類不同，單例類不能被直接實例化，只能是由自身實例化。因此，要獲得這樣的限制效果，構造函數必須標記為private。
要讓單例類不被直接實例化而能起到作用，就必須為其提供這樣的一個實例。因此，就必須要讓單例類擁有一個能保存類的實例的私有靜態成員變量和對應的一個能訪問到實例的公共靜態方法。
在PHP中，為防止對單例類對象的克隆來打破單例類的上述實現形式，通常還為基提供一個空的私有__clone()方法。好吧，廢話不多說，概括如下

單例模式有以下3個特點：

1．只能有一個實例,必須擁有一個構造函數，並且必須被標記為private

2．必須自行創建這個實例，擁有一個保存類的實例的靜態成員變量

3．必須給其他對象提供這一實例，擁有一個訪問這個實例的公共的靜態方法

單例類不能再其它類中直接實例化，只能被其自身實例化。它不會創建實例副本，而是會向單例類內部存儲的實例返回一個引用

那么為什么要使用PHP單例模式？

PHP一個主要應用場合就是應用程序與數據庫打交道的場景，在一個應用中會存在大量的數據庫操作，針對數據庫句柄連接數據庫的行為，使用單例模式可以避免大量的new操作。因為每一次new操作都會消耗系統和內存的資源。

在以往的項目開發中，沒使用單例模式前的情況如下：

//初始化一個數據庫句柄
$db = new DB(...);
//比如有個應用場景是添加一條評論信息
$db->addComment();
......
//如果我們要在另一地方使用這個評論信息，這時要用到數據庫句柄資源，可能會這么做
......
function comment() {
　　　$db = new DB(...);
　　　$db->getCommentInfo();
......
//可能有些朋友也許會說，可以直接使用global關鍵字！
　　　global $db;
......

的確global可以解決問題，也起到單例模式的作用，但在OOP中，我們建議拒絕這種編碼。因為global存在安全隱患（全局變量不受保護的本質）。

全局變量是面向對象程序員遇到的引發BUG的主要原因之一。這是因為全局變量將類捆綁於特定的環境，破壞了封裝。如果新的應用程序無法保證一開始就定義了相同的全局變量，那么一個依賴於全局變量的類就無法從一個應用程序中提取出來並應用到新應用程序中。

確切的講，單例模式恰恰是對全局變量的一種改進，避免那些存儲唯一實例的全局變量污染命名空間。你無法用錯誤類型的數據覆寫一個單例。這種保護在不支持命名空間的PHP版本里尤其重要。因為在PHP中命名沖突會在編譯時被捕獲，並使腳本停止運行。

我們用單例模式改進下示例：

class Single {
    private $name;//聲明一個私有的實例變量
    private function __construct(){//聲明私有構造方法為了防止外部代碼使用new來創建對象。
    
    }

    static public $instance;//聲明一個靜態變量（保存在類中唯一的一個實例）
    static public function getinstance(){//聲明一個getinstance()靜態方法，用於檢測是否有實例對象
        if(!self::$instance) self::$instance = new self();
        return self::$instance;
    }

    public function setname($n){ $this->name = $n; }
    public function getname(){ return $this->name; }
}

$oa = Single::getinstance();
$ob = Single::getinstance();
$oa->setname('hello php world');
$ob->setname('good morning php');
echo $oa->getname();//good morning php
echo $ob->getname();//good morning php

單例模式的優缺點：

優點：

1. 改進系統的設計

2. 是對全局變量的一種改進

缺點：

1. 難於調試

2. 隱藏的依賴關系

3. 無法用錯誤類型的數據覆寫一個單例

二、工廠模式

 工廠模式就是一種類，是指包含一個專門用來創建其他對象的方法的類，工廠類在多態性編程實踐中是至關重要的，它允許動態的替換類，修改配置，通常會使應用程序更加靈活，熟練掌握工廠模式高級PHP開發人員是很重要的。

 工廠模式通常用來返回符合類似接口的不同的類，工廠的一種常見用法就是創建多態的提供者，從而允許我們基於應用程序邏輯或者配置設置來決定應實例化哪一個類，例如，可以使用這樣的提供者來擴展一個類，而不需要重構應用程序的其他部分，從而使用新的擴展后的名稱 。

通常，工廠模式有一個關鍵的構造，根據一般原則命名為Factory的靜態方法，然而這只是一種原則，工廠方法可以任意命名，這個靜態還可以接受任意數據的參數，必須返回一個對象。

具有為您創建對象的某些方法，這樣就可以使用工廠類創建對象，工廠模式在於可以根據輸入參數或者應用程序配置的不同來創建一種專門用來實現化並返回其它類的實例的類，而不直接使用new，這樣如果想更改創建的對象類型，只需更改該工廠即可，

先舉個示例吧：

<?php
class Factory {//創建一個基本的工廠類
    static public function fac($id){//創建一個返回對象實例的靜態方法
        if(1 == $id) return new A();
        elseif(2==$id) return new B();
        elseif(3==$id) return new C();
        return new D();
    }
}

interface FetchName {//創建一個接口
    public function getname();//
}

class A implements FetchName{
    private $name = "AAAAA";
    public function getname(){ return $this->name; }
}

class C implements FetchName{
    private $name = "CCCCC";
    public function getname(){ return $this->name; }
}
class B implements FetchName{
    private $name = "BBBBB";
    public function getname(){ return $this->name; }
}

class D implements FetchName{
    private $name = "DDDDD";
    public function getname(){ return $this->name; }
}


$o = Factory::fac(6);//調用工廠類中的方法
if($o instanceof FetchName){
  echo  $o->getname();//DDDDD
}

$p=Factory::fac(3);
echo $p->getname();//CCCCC

?>

個人意見，再說簡單點吧,PHP工廠模式就是用一個工廠方法來替換掉直接new對象的操作，就是為方便擴展，方便使用，在新增實現基類中的類中方法時候，那么在工廠類中無需修改，傳入參數可以直接使用，具體就是跳過工廠類修改，直接使用工廠類輸出想要的結果。在傳統習慣中，如果要生成一個類的話，在代碼中直接new一個對象，比如：

class Database{
    
}
 
$db = new Database();

下面介紹工廠模式的操作方法:

class Database{  
 
}
 
//創建一個工廠類
class Factory
{
   //創建一個靜態方法
   static function createDatabase(){
       $db = new Database;
       return $db;
   }
}

那么，當我們想創建一個數據庫類的話，就可以使用這樣的方法:

<?php 
    $db = Factory::createDatabase();
?>

簡單工廠模式比直接new一個對象的好處是，比如Database這個類在很多php文件中都有使用到，當Database這個類發生了某些變更，比如修改了類名、或者一些參數發生了變化，那這時候如果你使用的是$db = new Database這種傳統方法生成對象，那么在所有包含這種生成對象的php文件代碼中都要進行修改。而使用工廠模式，只要在工廠方法或類里面進行修改即可。而且工廠模式是其他設計模式的基礎。
對上面的簡單工廠模式再進一步優化，比如:

 利用工廠類生產對象:

<?php
class Example
{
    // The parameterized factory method
    public static function factory($type)
    {
        if (include_once 'Drivers/' . $type . '.php') {
            $classname = 'Driver_' . $type;
            return new $classname;
        } else {
            throw new Exception('Driver not found');
        }
    }
}
 
// Load a MySQL Driver
$mysql = Example::factory('MySQL');
 
// Load an SQLite Driver
$sqlite = Example::factory('SQLite');
?>

簡單工廠模式又稱靜態工廠方法模式。從命名上就可以看出這個模式一定很簡單。它存在的目的很簡單：定義一個用於創建對象的接口。
要理解工廠模式這個概念，讓我們最好談一下許多開發人員從事大型系統的艱苦歷程。在更改一個代碼片段時，就會發生問題，系統其他部分 —— 您曾認為完全不相關的部分中也有可能出現級聯破壞。
該問題在於緊密耦合 。系統某個部分中的函數和類嚴重依賴於系統的其他部分中函數和類的行為和結構。您需要一組模式，使這些類能夠相互通信，但不希望將它們緊密綁定在一起，以避免出現聯鎖。
在大型系統中，許多代碼依賴於少數幾個關鍵類。需要更改這些類時，可能會出現困難。例如，假設您有一個從文件讀取的 User 類。您希望將其更改為從數據庫讀取的其他類，但是，所有的代碼都引用從文件讀取的原始類。這時候，使用工廠模式會很方便。

看下實例：

<?php
 
    interface IUser
    {
      function getName();
    }
 
    class User implements IUser
    {        
      public $id;
      public function __construct( $id ) { }
 
      public function getName()
      {
        return "Fantasy";
      }
    }
?>

傳統方法使用 User 類，一般都是這樣：

<?php
//在頁面1
$obj = new User(1);
 
//在頁面2
$obj2 = new User(2);
 
//在頁面3
$obj3 = new User(3);
....

?>

這時候，由於新的需求，使得User類要新增個參數或者User類名稱發生變化，User 類代碼發生變動，即：

<?php
class User implements IUser
{
  public $id,$pre;
  public function __construct( $id , $pre = '') {...}
 
  public function getName()
  {
    return $this->pre."Fantasy";
  }
}

?>

接着，恐怖的事情發生了，假設之前有 100 個頁面引用了之前的 User 類，那么這 100 個頁面都要發生相應的改動：

//在頁面1
$obj = new User(1,'aaa');
 
//在頁面2
$obj = new User(2,'aaa');
 
//在頁面3
$obj = new User(3,'aaa');
...

本來是一個小小的改動，但因緊密耦合的原因使得改動大吐血。而使用工廠模式則可以避免發生這種情況：

//User類為變動前
class UserFactory
{
  public static function Create( $id )
  {
    return new User( $id );
  }
}
 
//頁面1
$uo1 = UserFactory::Create( 1 );
 
//頁面2
$uo12 = UserFactory::Create( 2 );
....

這時候需求變動，User 類也發生變動：

<?php
class User implements IUser
{
  public $id,$pre;
  public function __construct( $id , $pre = '') {...}
 
  public function getName()
  {
    return $this->pre."Jack";
  }
}
?>

但是，我們不再需要去改動這 100 個頁面，我們要改的僅僅是這個工廠類：

//
class UserFactory
{
  public static function Create( $id,$pre = 'aaa' )
  {
    return new User( $id ,$pre);
  }
}

其他100個頁面不用做任何改動，這就是工廠設計模式帶來的好處。看下UML圖：

三、觀察者模式
觀察者模式為您提供了避免組件之間緊密耦合的另一種方法。該模式非常簡單：觀察者模式是一種事件系統，意味着這一模式允許某個類觀察另一個類的狀態，當被觀察的類狀態發生改變的時候，觀察類可以收到通知並且做出相應的動作;

現在有兩派，有的人建議使用設計模式，有的人不建議使用設計模式！
這就好比寫文章一樣，有的人喜歡文章按照套路走，比如敘事性質的文章，時間，地點，人物，事件。而有的人喜歡寫雜文或者散文，有的人喜歡寫詩詞！
現在寫代碼很多地方類似於寫文章，但是在有些地方比寫文章需要更多的技能！寫文章寫多了一般也能寫出優秀的文章，而代碼也一樣，寫多了也能寫出很多有寫的代碼！
很多時候，我看設計模式的時候，有些設計模式只是吻合我的代碼習慣。但是你硬去套它，那么反而適得其反。——很多時候是學會了招式，在應用中不知不覺的使用上這些招式，才能掌握其道，但是也不要拘泥於招式，正所謂“無招勝有招”嗎?

我學設計模式的初衷，就是知道有這么個玩意兒？腦子里有這么個印象，也不會生套它！如果設計模式不符合你的習慣對你閱讀代碼反而是不利的！

觀察者模式定義對象的一對多依賴,這樣一來，當一個對象改變狀態時，它的所有依賴者都會收到通知並自動更新!

設計原則 

在觀察者模式中，會改變的是主題的狀態以及觀察者的數目。用這個模式，你可以改變依賴於主題狀態的對象，卻不必改變主題。——找出程序中會變化的方面，然后將其和固定不變的方面相分離!

 

主題和觀察者都使用接口:觀察者利用主題的接口向主題注冊，而主題利用觀察者接口通知觀察者。這樣可以讓兩者之間運作正常，又同時具有松耦合的優點! ——針對接口編程，不針對實現編程!

 

觀察者模式利用“組合”將許多觀察者組合進主題中。對象(觀察者——主題)之間的這種關系不是通過繼承產生的，而是在運行時利用組合的方式產生的。 ——多用組合，少用繼承！

好了，不說太多廢話，直接上代碼：

<?php
/**
 * 觀察者模式
 * @author: Fantasy
 * @date: 2017/02/17
 */
 
class Paper{ /* 主題    */
    private $_observers = array();
 
    public function register($sub){ /*  注冊觀察者 */
        $this->_observers[] = $sub;
    }
     
    public function trigger(){  /*  外部統一訪問    */
        if(!empty($this->_observers)){
            foreach($this->_observers as $observer){
                $observer->update();
            }
        }
    }
}
 
/**
 * 觀察者要實現的接口
 */
interface Observerable{
    public function update();
}
 
class Subscriber implements Observerable{
    public function update(){
        echo "Callback\n";
    }
}
?>

下面是測試代碼:

/*  測試    */
$paper = new Paper();
$paper->register(new Subscriber());
//$paper->register(new Subscriber1());
//$paper->register(new Subscriber2());
$paper->trigger();

總結

       當新對象要填入的時候，只需要在主題(又叫可觀察者)中進行注冊(注冊方式很多，你也可以在構造的時候，或者框架訪問的接口中進行注冊),然后實現代碼直接在新對象的接口中進行。這降低了主題對象和觀察者對象的耦合度。

好的設計模式不會直接進入你的代碼中，而是進入你的大腦中。