php常見的設計模式

工廠模式

最初在設計模式 一書中，許多設計模式都鼓勵使用鬆散耦合。要理解這個概念，讓咱們最好談一下許多開發人員從事大型系統的艱苦歷程。在更改一個代碼片斷時，就會發生問題，系統其餘部分 —— 您曾認爲徹底不相關的部分中也有可能出現級聯破壞。

該問題在於緊密耦合 。系統某個部分中的函數和類嚴重依賴於系統的其餘部分中函數和類的行爲和結構。您須要一組模式，使這些類可以相互通訊，但不但願將它們緊密綁定在一塊兒，以免出現聯鎖。

在大型系統中，許多代碼依賴於少數幾個關鍵類。須要更改這些類時，可能會出現困難。例如，假設您有一個從文件讀取的 User 類。您但願將其更改成從數據庫讀取的其餘類，可是，全部的代碼都引用從文件讀取的原始類。這時候，使用工廠模式會很方便。

工廠模式 是一種類，它具備爲您建立對象的某些方法。您可使用工廠類建立對象，而不直接使用 new。這樣，若是您想要更改所建立的對象類型，只需更改該工廠便可。使用該工廠的全部代碼會自動更改。

清單 1 顯示工廠類的一個示列。等式的服務器端包括兩個部分：數據庫和一組 PHP 頁面，這些頁面容許您添加反饋、請求反饋列表並獲取與特定反饋相關的文章。

清單 1. Factory1.php

<?php
interface IUser
{
  function getName();
}

class User implements IUser
{
  public function __construct( $id ) { }

  public function getName()
  {
    return "Jack";
  }
}

class UserFactory
{
  public static function Create( $id )
  {
    return new User( $id );
  }
}

$uo = UserFactory::Create( 1 );
echo( $uo->getName()."\n" );
?>

IUser 接口定義用戶對象應執行什麼操做。IUser 的實現稱爲 User，UserFactory 工廠類則建立 IUser 對象。此關係能夠用圖 1 中的 UML 表示。

圖 1. 工廠類及其相關 IUser 接口和用戶類

若是您使用 php 解釋器在命令行上運行此代碼，將獲得以下結果：

% php factory1.php 
Jack
%

測試代碼會向工廠請求 User 對象，並輸出 getName 方法的結果。

有一種工廠模式的變體使用工廠方法。類中的這些公共靜態方法構造該類型的對象。若是建立此類型的對象很是重要，此方法很是有用。例如，假設您須要先建立對象，而後設置許多屬性。此版本的工廠模式會將該進程封裝在單個位置中，這樣，不用複製複雜的初始化代碼，也沒必要將複製好的代碼在在代碼庫中處處粘貼。

清單 2 顯示使用工廠方法的一個示例。

清單 2. Factory2.php

<?php
interface IUser
{
  function getName();
}

class User implements IUser
{
  public static function Load( $id ) 
  {
        return new User( $id );
  }

  public static function Create( ) 
  {
        return new User( null );
  }

  public function __construct( $id ) { }

  public function getName()
  {
    return "Jack";
  }
}

$uo = User::Load( 1 );
echo( $uo->getName()."\n" );
?>

這段代碼要簡單得多。它僅有一個接口 IUser 和一個實現此接口的 User 類。User 類有兩個建立對象的靜態方法。此關係可用圖 2 中的 UML 表示。

圖 2. IUser 接口和帶有工廠方法的 user 類

在命令行中運行腳本產生的結果與清單 1 的結果相同，以下所示：

% php factory2.php 
Jack
%

如上所述，有時此類模式在規模較小的環境中彷佛有些大材小用。不過，最好仍是學習這種紮實的編碼形式，以便應用於任意規模的項目中。

單元素模式

某些應用程序資源是獨佔的，由於有且只有一個此類型的資源。例如，經過數據庫句柄到數據庫的鏈接是獨佔的。您但願在應用程序中共享數據庫句柄，由於在保持鏈接打開或關閉時，它是一種開銷，在獲取單個頁面的過程當中更是如此。

單元素模式能夠知足此要求。若是應用程序每次包含且僅包含一個對象，那麼這個對象就是一個單元素（Singleton）。清單 3 中的代碼顯示了 PHP V5 中的一個數據庫鏈接單元素。

清單 3. Singleton.php

<?php
require_once("DB.php");

class DatabaseConnection
{
  public static function get()
  {
    static $db = null;
    if ( $db == null )
      $db = new DatabaseConnection();
    return $db;
  }

  private $_handle = null;

  private function __construct()
  {
    $dsn = 'mysql://root:password@localhost/photos';
    $this->_handle =& DB::Connect( $dsn, array() );
  }
  
  public function handle()
  {
    return $this->_handle;
  }
}

print( "Handle = ".DatabaseConnection::get()->handle()."\n" );
print( "Handle = ".DatabaseConnection::get()->handle()."\n" );
?>

此代碼顯示名爲 DatabaseConnection 的單個類。您不能建立自已的 DatabaseConnection，由於構造函數是專用的。但使用靜態 get 方法，您能夠得到且僅得到一個 DatabaseConnection 對象。此代碼的 UML 如圖 3 所示。

圖 3. 數據庫鏈接單元素

在兩次調用間，handle 方法返回的數據庫句柄是相同的，這就是最好的證實。您能夠在命令行中運行代碼來觀察這一點。

% php singleton.php 
Handle = Object id #3
Handle = Object id #3
%

返回的兩個句柄是同一對象。若是您在整個應用程序中使用數據庫鏈接單元素，那麼就能夠在任何地方重用同一句柄。

您可使用全局變量存儲數據庫句柄，可是，該方法僅適用於較小的應用程序。在較大的應用程序中，應避免使用全局變量，並使用對象和方法訪問資源。

觀察者模式

觀察者模式爲您提供了避免組件之間緊密耦合的另外一種方法。該模式很是簡單：一個對象經過添加一個方法（該方法容許另外一個對象，即觀察者 註冊本身）使自己變得可觀察。當可觀察的對象更改時，它會將消息發送到已註冊的觀察者。這些觀察者使用該信息執行的操做與可觀察的對象無關。結果是對象能夠相互對話，而沒必要了解緣由。

一個簡單示例是系統中的用戶列表。清單 4 中的代碼顯示一個用戶列表，添加用戶時，它將發送出一條消息。添加用戶時，經過發送消息的日誌觀察者能夠觀察此列表。

清單 4. Observer.php

<?php
interface IObserver
{
  function onChanged( $sender, $args );
}

interface IObservable
{
  function addObserver( $observer );
}

class UserList implements IObservable
{
  private $_observers = array();

  public function addCustomer( $name )
  {
    foreach( $this->_observers as $obs )
      $obs->onChanged( $this, $name );
  }

  public function addObserver( $observer )
  {
    $this->_observers []= $observer;
  }
}

class UserListLogger implements IObserver
{
  public function onChanged( $sender, $args )
  {
    echo( "'$args' added to user list\n" );
  }
}

$ul = new UserList();
$ul->addObserver( new UserListLogger() );
$ul->addCustomer( "Jack" );
?>

此代碼定義四個元素：兩個接口和兩個類。IObservable 接口定義能夠被觀察的對象，UserList 實現該接口，以便將自己註冊爲可觀察。IObserver 列表定義要經過怎樣的方法才能成爲觀察者，UserListLogger 實現 IObserver 接口。圖 4 的 UML 中展現了這些元素。

圖 4. 可觀察的用戶列表和用戶列表事件日誌程序

若是在命令行中運行它，您將看到如下輸出：

% php observer.php 
'Jack' added to user list
%

測試代碼建立 UserList，並將 UserListLogger 觀察者添加到其中。而後添加一個消費者，並將這一更改通知 UserListLogger。

認識到 UserList 不知道日誌程序將執行什麼操做很關鍵。可能存在一個或多個執行其餘操做的偵聽程序。例如，您可能有一個向新用戶發送消息的觀察者，歡迎新用戶使用該系統。這種方法的價值在於 UserList 忽略全部依賴它的對象，它主要關注在列表更改時維護用戶列表併發送消息這一工做。

此模式不限於內存中的對象。它是在較大的應用程序中使用的數據庫驅動的消息查詢系統的基礎。

命令鏈模式

命令鏈 模式以鬆散耦合主題爲基礎，發送消息、命令和請求，或經過一組處理程序發送任意內容。每一個處理程序都會自行判斷本身可否處理請求。若是能夠，該請求被處理，進程中止。您能夠爲系統添加或移除處理程序，而不影響其餘處理程序。清單 5 顯示了此模式的一個示例。

清單 5. Chain.php

<?php
interface ICommand
{
  function onCommand( $name, $args );
}

class CommandChain
{
  private $_commands = array();

  public function addCommand( $cmd )
  {
    $this->_commands []= $cmd;
  }

  public function runCommand( $name, $args )
  {
    foreach( $this->_commands as $cmd )
    {
      if ( $cmd->onCommand( $name, $args ) )
        return;
    }
  }
}

class UserCommand implements ICommand
{
  public function onCommand( $name, $args )
  {
    if ( $name != 'addUser' ) return false;
    echo( "UserCommand handling 'addUser'\n" );
    return true;
  }
}

class MailCommand implements ICommand
{
  public function onCommand( $name, $args )
  {
    if ( $name != 'mail' ) return false;
    echo( "MailCommand handling 'mail'\n" );
    return true;
  }
}

$cc = new CommandChain();
$cc->addCommand( new UserCommand() );
$cc->addCommand( new MailCommand() );
$cc->runCommand( 'addUser', null );
$cc->runCommand( 'mail', null );
?>

此代碼定義維護 ICommand 對象列表的 CommandChain 類。兩個類均可以實現 ICommand 接口 —— 一個對郵件的請求做出響應，另外一個對添加用戶做出響應。 圖 5 給出了 UML。

圖 5. 命令鏈及其相關命令

若是您運行包含某些測試代碼的腳本，則會獲得如下輸出：

% php chain.php 
UserCommand handling 'addUser'
MailCommand handling 'mail'
%

代碼首先建立 CommandChain 對象，併爲它添加兩個命令對象的實例。而後運行兩個命令以查看誰對這些命令做出了響應。若是命令的名稱匹配 UserCommand 或 MailCommand，則代碼失敗，不發生任何操做。

爲處理請求而建立可擴展的架構時，命令鏈模式頗有價值，使用它能夠解決許多問題。

策略模式

咱們講述的最後一個設計模式是策略 模式。在此模式中，算法是從複雜類提取的，於是能夠方便地替換。例如，若是要更改搜索引擎中排列頁的方法，則策略模式是一個不錯的選擇。思考一下搜索引擎的幾個部分 —— 一部分遍歷頁面，一部分對每頁排列，另外一部分基於排列的結果排序。在複雜的示例中，這些部分都在同一個類中。經過使用策略模式，您可將排列部分放入另外一個類中，以便更改頁排列的方式，而不影響搜索引擎的其他代碼。

做爲一個較簡單的示例，清單 6 顯示了一個用戶列表類，它提供了一個根據一組即插即用的策略查找一組用戶的方法。

清單 6. Strategy.php

<?php
interface IStrategy
{
  function filter( $record );
}

class FindAfterStrategy implements IStrategy
{
  private $_name;

  public function __construct( $name )
  {
    $this->_name = $name;
  }

  public function filter( $record )
  {
    return strcmp( $this->_name, $record ) <= 0;
  }
}

class RandomStrategy implements IStrategy
{
  public function filter( $record )
  {
    return rand( 0, 1 ) >= 0.5;
  }
}

class UserList
{
  private $_list = array();

  public function __construct( $names )
  {
    if ( $names != null )
    {
      foreach( $names as $name )
      {
        $this->_list []= $name;
      }
    }
  }

  public function add( $name )
  {
    $this->_list []= $name;
  }

  public function find( $filter )
  {
    $recs = array();
    foreach( $this->_list as $user )
    {
      if ( $filter->filter( $user ) )
        $recs []= $user;
    }
    return $recs;
  }
}

$ul = new UserList( array( "Andy", "Jack", "Lori", "Megan" ) );
$f1 = $ul->find( new FindAfterStrategy( "J" ) );
print_r( $f1 );

$f2 = $ul->find( new RandomStrategy() );
print_r( $f2 );
?>

此代碼的 UML 如圖 6 所示。

圖 6. 用戶列表和用於選擇用戶的策略

UserList 類是打包名稱數組的一個包裝器。它實現 find 方法，該方法利用幾個策略之一來選擇這些名稱的子集。這些策略由 IStrategy 接口定義，該接口有兩個實現：一個隨機選擇用戶，另外一個根據指定名稱選擇其後的全部名稱。運行測試代碼時，將獲得如下輸出：

% php strategy.php 
Array
(
    [0] => Jack
    [1] => Lori
    [2] => Megan
)
Array
(
    [0] => Andy
    [1] => Megan
)
%

測試代碼爲兩個策略運行同一用戶列表，並顯示結果。在第一種狀況中，策略查找排列在 J 後的任何名稱，因此您將獲得 Jack、Lori 和 Megan。第二個策略隨機選取名稱，每次會產生不一樣的結果。在這種狀況下，結果爲 Andy 和 Megan。

策略模式很是適合複雜數據管理系統或數據處理系統，兩者在數據篩選、搜索或處理的方式方面須要較高的靈活性。