更好的構造開發模板五種PHP設計模式

作者：Eve Cole 更新時間：2009-06-01 18:19:49

設計模式只是為Java 架構師準備的— 至少您可能一直這麼認為。實際上，設計模式對於每個人都非常有用。如果這些工具不是「架構太空人」的專利，那麼它們又是什麼？為什麼說它們在PHP 應用程式中非常有用？本文解釋了這些問題。

設計模式一書將設計模式引入軟體社區，該書的作者是Erich Gamma、Richard Helm、Ralph Johnson 和John Vlissides Design（俗稱「四人幫」）。所介紹的設計模式背後的核心概念非常簡單。經過多年的軟體開發實踐，Gamma 等人發現了某些具有固定設計的模式，就像建築師設計房子和建築物一樣，可以為浴室的位置或廚房的構造方式開發模板。使用這些模板或說設計模式意味著可以更快地設計更好的建築物。同樣的概念也適用於軟體。

設計模式不僅代表著更快開發健壯軟體的有用方法，而且還提供了以友善的術語封裝大型理念的方法。例如，您可以說您正在編寫一個提供鬆散耦合的訊息傳遞系統，也可以說您正在編寫名稱為觀察者的模式。

用較小的範例展示模式的價值是非常困難的。這往往有些大材小用的意味，因為模式實際上是在大型程式碼庫中發揮作用的。本文不展示大型應用程序，所以您需要思索的是在您自己的大型應用程式中應用範例原理的方法—— 而不是本文演示的程式碼本身。這不是說您不應該在小應用程式中使用模式。許多好的應用程式都以小型應用程式為起點，逐漸發展到大型應用程序，所以沒有理由不以此類紮實的編碼實踐為基礎。既然您已經了解了設計模式以及它們的有用之處，現在我們來看看PHP V5 的五種常用模式。

工廠模式

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

該問題在於緊密耦合。系統某個部分中的函數和類別嚴重依賴系統的其他部分中函數和類別的行為和結構。您需要一組模式，使這些類別能夠相互通信，但不希望將它們緊密綁定在一起，以避免出現聯鎖。在大型系統中，許多程式碼依賴少數幾個關鍵類別。需要更改這些類別時，可能會出現困難。例如，假設您有一個從檔案讀取的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 listn" );
}
}

$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 );
?＞

圖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。

策略模式非常適合複雜資料管理系統或資料處理系統，二者在資料篩選、搜尋或處理的方式上需要較高的彈性。

結束語

本文介紹的僅僅是PHP 應用程式中使用的幾種最常見的設計模式。在設計模式一書中示範了更多的設計模式。不要因架構的神秘性而放棄。模式是一種絕妙的理念，適用於任何程式語言、任何技能水平。