共通の PHP 設計パターンの共有-PHPチュートリアル-php.cn

『デザインパターン』という本は、ソフトウェアコミュニティにデザインパターンを紹介しました。この本の著者は、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.ph

<?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 インターフェイスとユーザークラス

工厂类及其相关 IUser 接口和用户类

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

<	% php Factory1.php ジャック %

测试代码会向工厂请求 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 类

IUser 接口和带有工厂方法的用户类

在命令行中运行脚本产生的结果与清单 1 的结果相同，如下所示：

1
2
3

%
 php factory2.php
Jack
%ログイン後にコピー

如上所述，有时此类模式在规模较小的环境中似乎有些大材小用。不过，最好还是学习这种扎实的编码形式，以便应用于任意规模的项目中。

单元素模式

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

单元素模式可以满足此要求。如果应用程序每次包含且仅包含一个对象，那么这个对象就是一个单元素（Singleton）。清单 3 中的代码显示了 PHP V5 中的一个共通の PHP 設計パターンの共有。

清单 3. Singleton.php

<?php
require_once("DB.php");
 
class
 DatabaseConnection
{
  public
 static function get()
  {
    static
 $db= null;
    if
 ( $db == null )
      $db= newDatabaseConnection();
    return
 $db;
  }
 
  private
 $_handle= null;
 
  private
 function __construct()
  {
    $dsn= &#39;mysql://root:password@localhost/photos&#39;;
    $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. 共通の PHP 設計パターンの共有

共通の PHP 設計パターンの共有

在两次调用间，handle 方法返回的数据库句柄是相同的，这就是最好的证明。您可以在命令行中运行代码来观察这一点。

%
 php singleton.php
Handle
 = Object id #3
Handle
 = Object id #3
%ログイン後にコピー

返回的两个句柄是同一对象。如果您在整个应用程序中使用共通の PHP 設計パターンの共有，那么就可以在任何地方重用同一句柄。

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

观察者模式

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

一个简单示例是系统中的用户列表。清单 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(
 "&#39;$args&#39; added to user list\n" );
  }
}
 
$ul
 = new UserList();
$ul->addObserver(
 new UserListLogger() );
$ul->addCustomer(
 "Jack" );
?>ログイン後にコピー

此代码定义四个元素：两个接口和两个类。IObservable 接口定义可以被观察的对象，UserList 实现该接口，以便将本身注册为可观察。IObserver 列表定义要通过怎样的方法才能成为观察者，UserListLogger 实现 IObserver 接口。图 4 的 UML 中展示了这些元素。

图 4. 共通の PHP 設計パターンの共有

共通の PHP 設計パターンの共有

如果在命令行中运行它，您将看到以下输出：

%
 php observer.php
&#39;Jack&#39;
 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 != &#39;addUser&#39; ) return false;
    echo(
 "UserCommand handling &#39;addUser&#39;\n" );
    return
 true;
  }
}
 
class
 MailCommand implements ICommand
{
  public
 function onCommand( $name, $args )
  {
    if
 ( $name != &#39;mail&#39; ) return false;
    echo(
 "MailCommand handling &#39;mail&#39;\n" );
    return
 true;
  }
}
 
$cc
 = new CommandChain();
$cc->addCommand(
 new UserCommand() );
$cc->addCommand(
 new MailCommand() );
$cc->runCommand(
 &#39;addUser&#39;, null );
$cc->runCommand(
 &#39;mail&#39;, null );
?>ログイン後にコピー

このコードは、ICommand オブジェクトのリストを管理する CommandChain クラスを定義します。どちらのクラスも ICommand インターフェイスを実装できます - 1 つは電子メールのリクエストに応答し、もう 1 つはユーザーの追加に応答します。図 5 に UML を示します。

図 5. コマンドチェーンとその関連コマンド

共通の PHP 設計パターンの共有

テストコードを含むスクリプトを実行すると、次の出力が得られます:

%
 phpchain.php
ユーザーコマンド
 「addUser」
MailCommandの処理
 「メール」の処理
%

代码首先创建 CommandChain 对象，并为它添加两个命令对象的实例。然后运行两个命令以查看谁对这些命令作出了响应。如果命令的名称匹配 UserCommand 或 MailCommand，则代码失败，不发生任何操作。

为处理请求而创建可扩展的架构时，命令链模式很有价值，使用它可以解决许多问题。

策略模式

我们讲述的最后一个设计模式是策略模式。在此模式中，算法是从复杂类提取的，因而可以方便地替换。例如，如果要更改搜索引擎中排列页的方法，则策略模式是一个不错的选择。思考一下搜索引擎的几个部分 —— 一部分遍历页面，一部分对每页排列，另一部分基于排列的结果排序。在复杂的示例中，这些部分都在同一个类中。通过使用策略模式，您可将排列部分放入另一个类中，以便更改页排列的方式，而不影响搜索引擎的其余代码。

作为一个较简单的示例，清单 6 显示了一个用户列表类，它提供了一个根据一组即插即用的策略查找一组用户的方法。

清单 6. Strategy.php

<?phpinterface
 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. 共通の PHP 設計パターンの共有

共通の PHP 設計パターンの共有

UserList 类是打包名称数组的一个包装器。它实现 find 方法，该方法利用几个策略之一来选择这些名称的子集。这些策略由 IStrategy 接口定义，该接口有两个实现：一个随机选择用户，另一个根据指定名称选择其后的所有名称。运行测试代码时，将得到以下输出：

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

ログイン後にコピー

测试代码为两个策略运行同一用户列表，并显示结果。在第一种情况中，策略查找排列在 J 后的任何名称，所以您将得到 Jack、Lori 和 Megan。第二个策略随机选取名称，每次会产生不同的结果。在这种情况下，结果为 Andy 和 Megan。

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

结束语

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

以上が共通の PHP 設計パターンの共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

共通の PHP 設計パターンの共有

ファクトリー パターン

リスト 1. Factory1.ph

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

清单 2. Factory2.php

图 2. IUser 接口和带有工厂方法的 user 类

单元素模式

清单 3. Singleton.php

图 3. 共通の PHP 設計パターンの共有

观察者模式

清单 4. Observer.php

图 4. 共通の PHP 設計パターンの共有

命令链模式

清单 5. Chain.php

図 5. コマンド チェーンとその関連コマンド

策略模式

清单 6. Strategy.php

图 6. 共通の PHP 設計パターンの共有

结束语

ファクトリーパターン

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

図 5. コマンドチェーンとその関連コマンド