5 つの一般的な PHP 設計パターン

『Design Patterns』という本は、ソフトウェア コミュニティにデザイン パターンを紹介しました。この本の著者は、Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides Design (一般に「Gang of Four」として知られています) です。提示されたデザイン パターンの背後にある中心となる概念は非常にシンプルです。ソフトウェア開発を何年も実践した後、Gamma らは、建築家が家や建物を設計するのと同じように、バスルームをどこに配置するか、キッチンをどのように構築するかについてのテンプレートを開発するのと同じように、固定設計の特定のパターンを発見しました。これらのテンプレート、つまりデザイン パターンを使用すると、より良い建物をより速く設計できるようになります。同じ概念がソフトウェアにも当てはまります。

デザイン パターンは、堅牢なソフトウェアをより迅速に開発するための便利な方法を表すだけでなく、大きなアイデアをわかりやすい言葉でカプセル化する方法も提供します。たとえば、疎結合を提供するメッセージング システムを作成しているとも言えますし、Observer という名前のパターンを作成しているとも言えます。

より小さな例でパターンの価値を実証するのは非常に困難です。パターンは実際には大規模なコードベースで機能するため、これはやりすぎのように感じることがよくあります。この記事では大規模なアプリケーションについては説明しません。そのため、この記事で説明したコード自体ではなく、この例の原則を独自の大規模なアプリケーションに適用する方法を考える必要があります。これは、小規模なアプリケーションでパターンを使用するべきではないということではありません。優れたアプリケーションの多くは、小さなアプリケーションから始まり、大規模なアプリケーションに発展するため、このような堅固なコーディング手法に基づいて構築しない理由はありません。

デザイン パターンとその有用性について理解したところで、PHP V5 で一般的に使用される 5 つのパターンを見てみましょう。

ファクトリー パターン

元々は『デザイン パターン』という本の中で、多くのデザイン パターンが疎結合の使用を奨励しています。この概念を理解するには、多くの開発者が大規模システムで作業する際に経験する困難な旅について話すのが最善です。 1 つのコードを変更すると問題が発生する可能性があり、まったく関係ないと思われていたシステムの他の部分で連鎖的な中断が発生する可能性があります。

問題は密結合です。システムの一部の関数とクラスは、システムの他の部分の関数とクラスの動作と構造に大きく依存します。これらのクラスが相互に通信できるようにする一連のパターンが必要ですが、インターロックを避けるためにクラスをしっかりと結び付けることは望ましくありません。

大規模システムでは、多くのコードがいくつかの主要なクラスに依存しています。これらのクラスを変更する必要がある場合、問題が発生する可能性があります。たとえば、ファイルから読み取る User クラスがあるとします。これをデータベースから読み取る別のクラスに変更したいと考えていますが、コードはすべてファイルから読み取る元のクラスを参照しています。このとき、ファクトリーモードを使用すると非常に便利です。

Factory Pattern は、オブジェクトを作成する特定のメソッドを持つクラスです。 new を直接使用する代わりに、ファクトリ クラスを使用してオブジェクトを作成できます。このようにすると、作成されるオブジェクトのタイプを変更する場合は、ファクトリを変更するだけで済みます。このファクトリを使用するすべてのコードは自動的に変更されます。

リスト 1 は、ファクトリー クラスの例を示しています。この方程式のサーバー側は、データベースと、フィードバックの追加、フィードバックのリストの要求、および特定のフィードバックに関連する記事の取得を可能にする一連の PHP ページの 2 つの部分で構成されます。

リスト 1. Factory1.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 オブジェクトを作成します。この関係は、UML で図 1 に表すことができます。

図 1. ファクトリ クラスとそれに関連する IUser インターフェイスとユーザー クラス

php インタープリターを使用してコマンド ラインでこのコードを実行すると、次の結果が得られます:

% php factory1.php Jack%

テスト コードはリクエストを要求しますユーザーはファクトリーオブジェクトから取得し、getNameメソッドの結果を出力します。

ファクトリーメソッドを使用するファクトリーパターンのバリエーションがあります。クラス内のこれらのパブリック静的メソッドは、その型のオブジェクトを構築します。このメソッドは、このタイプのオブジェクトを作成することが重要な場合に役立ちます。たとえば、オブジェクトを作成し、いくつかのプロパティを設定する必要があるとします。このバージョンのファクトリ パターンはプロセスを 1 か所にカプセル化するため、複雑な初期化コードをコピーしてコード ベース全体に貼り付ける必要がありません。

リスト 2 は、ファクトリ メソッドの使用例を示しています。

リスト 2. Factory2.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 が 1 つと、このインターフェイスを実装する User クラスが 1 つだけあります。 User クラスには、オブジェクトを作成するための 2 つの静的メソッドがあります。この関係は、図 2 の UML で表すことができます。

図 2. ファクトリ メソッドを使用した IUser インターフェイスとユーザー クラス

コマンド ラインでスクリプトを実行すると、以下に示すように、リスト 1 と同じ結果が生成されます。小規模な環境では過剰に見えるかもしれません。ただし、あらゆる規模のプロジェクトに適用できる、この堅実なコーディング形式を学ぶことが最善です。

单元素模式

某些应用程序资源是独占的，因为有且只有一个此类型的资源。例如，通过数据库句柄到数据库的连接是独占的。您希望在应用程序中共享数据库句柄，因为在保持连接打开或关闭时，它是一种开销，在获取单个页面的过程中更是如此。

单元素模式可以满足此要求。如果应用程序每次包含且仅包含一个对象，那么这个对象就是一个单元素（Singleton）。清单 3 中的代码显示了 PHP V5 中的一个数据库连接单元素。

清单 3. Singleton.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 #3Handle = Object id #3%

　　

返回的两个句柄是同一对象。如果您在整个应用程序中使用数据库连接单元素，那么就可以在任何地方重用同一句柄。

您可以使用全局变量存储数据库句柄，但是，该方法仅适用于较小的应用程序。在较大的应用程序中，应避免使用全局变量，并使用对象和方法访问资源。

观察者模式

观察者模式为您提供了避免组件之间紧密耦合的另一种方法。该模式非常简单：一个对象通过添加一个方法（该方法允许另一个对象，即观察者 注册自己）使本身变得可观察。当可观察的对象更改时，它会将消息发送到已注册的观察者。这些观察者使用该信息执行的操作与可观察的对象无关。结果是对象可以相互对话，而不必了解原因。

一个简单示例是系统中的用户列表。清单 4 中的代码显示一个用户列表，添加用户时，它将发送出一条消息。添加用户时，通过发送消息的日志观察者可以观察此列表。

清单 4. Observer.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

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

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。

策略模式非常适合复杂数据管理系统或数据处理系统，二者在数据筛选、搜索或处理的方式方面需要较高的灵活性。

结束语

本文介绍的仅仅是 PHP 应用程序中使用的几种最常见的设计模式。在设计模式 一书中演示了更多的设计模式。不要因架构的神秘性而放弃。模式是一种绝妙的理念，适用于任何编程语言、任何技能水平。