ホーム>ネットワークプログラミングチュートリアル

開発テンプレートをより適切に構築するための 5 つの PHP 設計パターン

著者：Eve Cole 更新時間：2009-06-01 18:19:49
デザイン パターンは Java アーキテクトのためのものです - 少なくとも、あなたは常にそう思っているかもしれません。実際、デザインパターンは誰にとっても役立ちます。これらのツールが「建築宇宙飛行士」の所有物でないとしたら、それは何でしょうか?これらが PHP アプリケーションで役立つのはなぜですか?この記事ではこれらの問題について説明します。

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

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

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

工場出荷時のパターン

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

問題は密結合です。システムの一部の関数とクラスは、システムの他の部分の関数とクラスの動作と構造に大きく依存します。これらのクラスが相互に通信できるようにする一連のパターンが必要ですが、インターロックを避けるためにクラスをしっかりと結び付けることは望ましくありません。 大規模システムでは、多くのコードがいくつかの主要なクラスに依存しています。これらのクラスを変更する必要がある場合、問題が発生する可能性があります。たとえば、ファイルから読み取る User クラスがあるとします。これをデータベースから読み取る別のクラスに変更したいと考えていますが、コードはすべてファイルから読み取る元のクラスを参照しています。このとき、ファクトリーモードを使用すると非常に便利です。

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

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

リスト 1. Factory1.php

<?php
インターフェイス IUser
{
関数 getName();
}

ユーザーが IUser を実装するクラス
{
パブリック関数 __construct( $id ) { }

パブリック関数 getName()
{
「ジャック」を返します。
}
}

クラスUserFactory
{
パブリック静的関数 Create( $id )
{
新しいユーザー( $id )を返します;
}
}

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

IUser インターフェイスは、ユーザー オブジェクトが実行する必要があるアクションを定義します。 IUser の実装は User と呼ばれ、UserFactory ファクトリ クラスが IUser オブジェクトを作成します。この関係は、図 1 の UML で表すことができます。


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

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

%phpfactory1.php
ジャック
%

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

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

リスト 2. Factory2.php

<?php
インターフェイス IUser
{
関数 getName();
}

ユーザーが IUser を実装するクラス
{
パブリック静的関数 Load( $id )
{
新しいユーザー( $id )を返します;
}

パブリック静的関数 Create( )
{
新しいユーザーを返します( null );
}

パブリック関数 __construct( $id ) { }

パブリック関数 getName()
{
「ジャック」を返します。
}
}

$uo = ユーザー::Load( 1 );
echo( $uo->getName()."n" );
?＞

このコードははるかに単純です。インターフェイス IUser が 1 つと、このインターフェイスを実装する User クラスが 1 つだけあります。 User クラスには、オブジェクトを作成するための 2 つの静的メソッドがあります。この関係は、図 2 の UML で表すことができます。


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

コマンド ラインでスクリプトを実行すると、次のようにリスト 1 と同じ結果が生成されます。

%phpfactory2.php
ジャック
%


上で述べたように、小規模な環境では、このようなモードは過剰に見える場合があります。ただし、あらゆる規模のプロジェクトに適用できる、この堅実なコーディング形式を学ぶことが最善です。

単一要素モード

一部のアプリケーション リソースは、このタイプのリソースが 1 つしかないため、排他的になります。たとえば、データベース ハンドルを介したデータベースへの接続は排他的です。アプリケーション全体でデータベース ハンドルを共有する必要があるのは、接続を開いたままにするか閉じたままにするときにオーバーヘッドが発生するためであり、単一ページをフェッチするプロセスではさらにオーバーヘッドがかかるからです。

単一要素モードはこの要件を満たします。アプリケーションに一度に 1 つのオブジェクトだけが含まれる場合、このオブジェクトはシングルトンです。リスト 3 のコードは、PHP V5 のデータベース接続の単一要素を示しています。

リスト 3. Singleton.php

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

クラスデータベース接続
{
パブリック静的関数 get()
{
静的 $db = null;
if ( $db == null )
$db = 新しいデータベース接続();
$db を返します。
}

プライベート $_handle = null;
プライベート関数 __construct()
{
$dsn = 'mysql://root:パスワード@localhost/photos';
$this->_handle =& DB::Connect( $dsn, array() );
}

パブリック関数ハンドル()
{
$this->_handle を返します。
}
}

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

このコードは、DatabaseConnection という名前の単一クラスを示しています。コンストラクターはプライベートであるため、独自の DatabaseConnection を作成することはできません。ただし、静的 get メソッドを使用すると、DatabaseConnection オブジェクトを 1 つだけ取得できます。このコードの UML を図 3 に示します。


図 3. データベース接続の単一要素

最良の証拠は、handle メソッドによって返されるデータベース ハンドルが 2 つの呼び出し間で同じであることです。コマンドラインでコードを実行すると、これを確認できます。

% php シングルトン.php
ハンドル = オブジェクト ID #3
ハンドル = オブジェクト ID #3
%

返される 2 つのハンドルは同じオブジェクトです。アプリケーション全体でデータベース接続の単一要素を使用すると、どこでも同じハンドルを再利用できます。

グローバル変数を使用してデータベース ハンドルを保存できますが、このアプローチは小規模なアプリケーションにのみ適しています。大規模なアプリケーションでは、グローバル変数の使用を避け、オブジェクトとメソッドを使用してリソースにアクセスします。

オブザーバーパターン

Observer パターンは、コンポーネント間の密結合を回避する別の方法を提供します。パターンは非常に単純です。オブジェクトは、別のオブジェクト (オブザーバー) が自分自身を登録できるようにするメソッドを追加することで、自分自身を監視可能にします。監視可能なオブジェクトが変化すると、登録されたオブザーバーにメッセージが送信されます。これらのオブザーバーは、この情報を使用して、監視可能なオブジェクトとは独立して操作を実行します。その結果、オブジェクトは理由を理解することなく相互に通信できるようになります。 簡単な例は、システム内のユーザーのリストです。リスト 4 のコードはユーザーのリストを表示し、ユーザーが追加されるとメッセージを送信します。このリストは、ユーザーが追加されたときにメッセージを送信するログ オブザーバーを介して監視できます。

リスト 4. Observer.php

<?php
インターフェース IObserver
{
関数 onChanged( $sender, $args );
}

インターフェース IObservable
{
関数 addObserver( $observer );
}

クラス UserList は IObservable を実装します
{
プライベート $_observers = array();

パブリック関数 addCustomer( $name )
{
foreach( $this->_observers as $obs )
$obs->onChanged( $this, $name );
}

パブリック関数 addObserver( $observer )
{
$this->_observers []= $observer;
}
}

クラス UserListLogger は IObserver を実装します
{
パブリック関数 onChanged( $sender, $args )
{
echo( "'$args' がユーザー リストに追加されましたn" );
}
}

$ul = 新しいユーザーリスト();
$ul->addObserver( new UserListLogger() );
$ul->addCustomer( "ジャック" );
?＞

このコードは、2 つのインターフェイスと 2 つのクラスの 4 つの要素を定義します。 IObservable インターフェイスは監視できるオブジェクトを定義し、UserList は自身を監視可能として登録するためにこのインターフェイスを実装します。 IObserver リストは、UserListLogger が IObserver インターフェイスを実装する方法を定義します。これらの要素を図 4 の UML に示します。


図 4. 監視可能なユーザー リストとユーザー リスト イベント ロガー

コマンドラインから実行すると、次の出力が表示されます。

% php オブザーバー.php
「ジャック」がユーザーリストに追加されました
%

テスト コードは UserList を作成し、それに UserListLogger オブザーバーを追加します。次に、コンシューマを追加し、この変更を UserListLogger に通知します。

UserList はロガーが何を行うかわからないことを認識することが重要です。他の操作を実行する 1 つ以上のリスナーが存在する場合があります。たとえば、新しいユーザーにシステムへの歓迎のメッセージを送信するオブザーバーがあるとします。このアプローチの価値は、UserList がそれに依存するすべてのオブジェクトを無視し、主にユーザーのリストを維持し、リストが変更されたときにメッセージを送信することに重点を置くことです。

このパターンはメモリ内のオブジェクトに限定されません。これは、大規模なアプリケーションで使用されるデータベース主導のメッセージ クエリ システムの基礎です。

一連のコマンドモード

コマンド チェーン パターンは疎結合トピックに基づいており、一連のハンドラーを通じてメッセージ、コマンド、リクエストなどを送信します。各ハンドラーは、リクエストを処理できるかどうかを独自に判断します。可能な場合、リクエストは処理され、プロセスは停止します。他のハンドラーに影響を与えることなく、システムにハンドラーを追加または削除できます。リスト 5 は、このパターンの例を示しています。

リスト 5. Chain.php

<?php
インターフェースIコマンド
{
関数 onCommand( $name, $args );
}

クラスコマンドチェーン
{
プライベート $_commands = array();

パブリック関数 addCommand( $cmd )
{
$this->_commands []= $cmd;
}

パブリック関数 runCommand( $name, $args )
{
foreach( $this->_commands as $cmd )
{
if ( $cmd->onCommand( $name, $args ) )
戻る;
}
}
}

クラス UserCommand は ICommand を実装します
{
パブリック関数 onCommand( $name, $args )
{
if ( $name != 'addUser' ) は false を返します。
echo( "UserCommand が 'addUser' を処理していますn" );
true を返します。
}
}

クラス MailCommand は ICommand を実装します
{
パブリック関数 onCommand( $name, $args )
{
if ( $name != 'mail' ) は false を返します。
echo( "'mail' を処理する MailCommandn" );
true を返します。
}
}

$cc = 新しいコマンドチェーン();
$cc->addCommand( new UserCommand() );
$cc->addCommand( new MailCommand() );
$cc->runCommand( 'addUser', null );
$cc->runCommand( 'メール', null );
?＞

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


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

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

%phpchain.php
「addUser」を処理する UserCommand
「メール」を処理する MailCommand
%

このコードは、まず CommandChain オブジェクトを作成し、コマンド オブジェクトの 2 つのインスタンスをそれに追加します。次に、2 つのコマンドを実行して、誰がコマンドに応答したかを確認します。コマンドの名前が UserCommand または MailCommand と一致する場合、コードは失敗し、アクションは発生しません。 コマンド チェーン パターンは、リクエストを処理するためのスケーラブルなアーキテクチャを作成する場合に役立ち、これを使用して多くの問題を解決できます。

戦略パターン

最後に取り上げるデザイン パターンは、戦略パターンです。このパターンでは、アルゴリズムが複雑なクラスから抽出されるため、簡単に置き換えることができます。たとえば、検索エンジンでのページのランク付け方法を変更したい場合は、戦略モードが適しています。検索エンジンの各部分、つまりページを横断する部分、各ページをランク付けする部分、およびランキングに基づいて結果を並べ替える部分について考えてみましょう。複雑な例では、これらのパーツはすべて同じクラスに属します。 Strategy パターンを使用すると、配置部分を別のクラスに配置して、検索エンジンのコードの残りの部分に影響を与えることなく、ページの配置方法を変更できます。

より簡単な例として、リスト 6 に、一連のプラグ アンド プレイ ポリシーに基づいて一連のユーザーを検索する方法を提供するユーザー リスト クラスを示します。

リスト 6. Strategy.php

<?php
インターフェイス I戦略
{
関数フィルター( $record );
}

クラス FindAfterStrategy は IStrategy を実装します
{
プライベート $_name;

パブリック関数 __construct( $name )
{
$this->_name = $name;
}

パブリック関数フィルター($record)
{
return strcmp( $this->_name, $record ) <= 0;
}
}

クラス RandomStrategy は IStrategy を実装します
{
パブリック関数フィルター($record)
{
戻り rand( 0, 1 ) ＞= 0.5;
}
}

クラスUserList
{
プライベート $_list = array();

パブリック関数 __construct( $names )
{
if ( $names != null )
{
foreach( $names として $name )
{
$this->_list []= $name;
}
}
}

パブリック関数 add( $name )
{
$this->_list []= $name;
}

パブリック関数 find( $filter )
{
$recs = 配列();
foreach( $this->_list as $user )
{
if ( $filter->filter( $user ) )
$recs []= $user;
}
$recs を返します。
}
}

$ul = new UserList( array( "アンディ", "ジャック", "ローリ", "ミーガン" ) );
$f1 = $ul->find( new FindAfterStrategy( "J" ) );
print_r( $f1 );

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


図 6. ユーザーの選択に使用されるユーザー リストとポリシー

UserList クラスは、名前の配列のラッパーです。これは、いくつかの戦略の 1 つを使用してこれらの名前のサブセットを選択する find メソッドを実装します。これらの戦略は、IStrategy インターフェイスによって定義されます。このインターフェイスには、ユーザーをランダムに選択する実装と、指定された名前以降のすべての名前を選択する実装の 2 つがあります。テスト コードを実行すると、次の出力が得られます。

%php 戦略.php
配列
(
[0] => ジャック
[1] =＞ロリ
[2] =＞ミーガン
)
配列
(
[0] => アンディ
[1] =＞ミーガン
)
%

テスト コードは、両方の戦略に対して同じユーザー リストを実行し、結果を表示します。最初のケースでは、戦略は J に続く名前を検索するため、Jack、Lori、Megan が得られます。 2 番目の戦略では、名前がランダムに選択され、毎回異なる結果が生成されます。この場合、結果はアンディとミーガンです。

Strategy パターンは、データのフィルタリング、検索、または処理方法に高度な柔軟性を必要とする複雑なデータ管理システムまたはデータ処理システムに最適です。

結論

この記事では、PHP アプリケーションで使用される最も一般的なデザイン パターンのほんの一部を紹介します。より多くのデザイン パターンについては、『デザイン パターン』という書籍で説明されています。建築の神秘性にがっかりしないでください。パターンは、どのプログラミング言語でも、どのスキル レベルでも機能する素晴らしいアイデアです。
関連記事