PHPのOOPアプリケーションでオブジェクトを初期化する問題。 レジストリ、ファクトリメソッド、サービスロケーター、および依存性注入パターンを使用したソリューションの検索

偶然にも、プログラマーが成功したソリューションを設計パターンの形で修正しました。 パターンに関する多くの文献があります。 Erich Gamma、Richard Helm、Ralph Johnson、John Vlissidesによる Four Gangsの「Design Patterns」の本と、おそらくMartin Fowlerによる「Patterns of Enterprise Application Architecture」は、古典と考えられています。 -これは、Matt Zandstraによる「PHPオブジェクト、パターン、および実践」です.OOPをマスターし始めたばかりの人々にとって、このすべての文献は非​​常に複雑であるため、非常に役立つと思われるいくつかのパターンを提示するというアイデアがありました簡略化：つまり、この記事はデザインパターンを解釈する最初の試みです。 KISSスタイル。

今日は、OOPアプリケーションでのオブジェクトの初期化で発生する可能性のある問題と、これらの問題を解決するための一般的なデザインパターンの使用方法について説明します。

例

最新のOOPアプリケーションは、数十、数百、時には数千のオブジェクトで動作します。 さて、アプリケーションでこれらのオブジェクトがどのように初期化されるかを詳しく見てみましょう。 この記事では、オブジェクトの初期化のみが関心のある側面であるため、「余分な」実装をすべて省略することにしました。

GETリクエストを特定のURIに送信し、サーバーの応答からHTMLを返すことができる非常に便利なクラスを作成したとしましょう。 クラスが単純すぎるように見えるのを防ぐために、結果を確認し、「間違った」サーバー応答の場合に例外をスローします。

class Grabber { public function get($url) {/** returns HTML code or throws an exception */} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果のHTMLのフィルタリングを担当するオブジェクトを持つ別のクラスを作成します。 filterメソッドは、HTMLコードとCSSセレクターを引数として受け取り、指定されたセレクターで見つかった要素の配列を返します。

 class HtmlExtractor { public function filter($html, $selector) {/** returns array of filtered elements */} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、指定されたキーワードのGoogle検索結果を取得する必要があると想像してください。 これを行うために、Grabberクラスを使用してリクエストを送信し、HtmlExtractorクラスを使用して必要なコンテンツを取得する別のクラスを導入します。 また、URI構築ロジック、受信したHTMLをフィルタリングし、受信した結果を処理するためのセレクターも含まれます。

 class GoogleFinder { private $grabber; private $filter; public function __construct() { $this->grabber = new Grabber(); $this->filter = new HtmlExtractor(); } public function find($searchString) { /** returns array of founded results */} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GrabberおよびHtmlExtractorオブジェクトの初期化は、GoogleFinderクラスのコンストラクターにあることに気づきましたか？ この決定がどれほど成功したかを考えてみましょう。

もちろん、コンストラクターでオブジェクトの作成をハードコーディングすることはお勧めできません。 そして、ここに理由があります。 まず、実際のリクエストの送信を避けるために、テスト環境でGrabberクラスを簡単に置き換えることはできません。 公平に言えば、これはReflection APIを使用して行うことができると言う価値があります 。 つまり 技術的な可能性は存在しますが、これは最も便利で明白な方法とはほど遠いものです。

次に、GoogleFinderロジックをGrabberおよびHtmlExtractorの他の実装で再利用したい場合、同じ問題が発生します。 依存関係の作成は、クラスのコンストラクターにハードコーディングされています。 最良の場合、GoogleFinderを継承し、そのコンストラクターをオーバーライドできます。 そして、それでも、グラバーとフィルターのプロパティのスコープが保護されているか、公開されている場合のみ。

最後の瞬間、新しいGoogleFinderオブジェクトを作成するたびに、メモリ内に新しい依存関係オブジェクトのペアが作成されますが、GoogleFinderタイプの複数のオブジェクトでGrabberタイプの1つのオブジェクトとHtmlExtractorタイプの1つのオブジェクトを使用できます。

依存関係の初期化はクラスの外に移動する必要があることを既に理解していると思います。 準備済みの依存関係をGoogleFinderクラスのコンストラクターに渡す必要がある場合があります。

 class GoogleFinder { private $grabber; private $filter; public function __construct(Grabber $grabber, HtmlExtractor $filter) { $this->grabber = $grabber; $this->filter = $filter; } public function find($searchString) { /** returns array of founded results */} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

他の開発者にGrabberとHtmlExtractorの実装を追加および使用する機会を提供したい場合、それらのインターフェイスを導入することを検討する価値があります。 この場合、それは有用であるだけでなく、必要でもあります。 プロジェクトで1つの実装のみを使用し、将来新しい実装を作成するつもりがない場合は、インターフェイスの作成を拒否する必要があると思います。 状況に応じて行動し、実際に必要が生じたときに簡単なリファクタリングを行うことをお勧めします。

これで、必要なクラスがすべて揃い、コントローラーでGoogleFinderクラスを使用できます。

 class Controller { public function action() { /* Some stuff */ $finder = new GoogleFinder(new Grabber(), new HtmlExtractor()); $results = $finder->find('search string'); /* Do something with results */ } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

小計を要約します。 私たちはごくわずかなコードを書きましたが、一見したところでは何も間違っていませんでした。 しかし... ... GoogleFinderのようなオブジェクトを他の場所で使用する必要がある場合はどうでしょうか？ その作成を複製する必要があります。 この例では、これは1行のみであり、問​​題はそれほど目立ちません。 実際には、オブジェクトの初期化は非常に複雑になる可能性があり、最大10行、またはそれ以上かかる場合があります。 コードの複製に典型的な他の問題も発生します。 リファクタリング中に、使用するクラスの名前またはオブジェクトの初期化のロジックを変更する必要がある場合、すべての場所を手動で変更する必要があります。 あなたはそれがどのように起こるか知っていると思う:)

通常、ハードコードは簡単です。 通常、重複する値は構成に配置されます。 これにより、使用されるすべての場所で値を一元的に変更できます。

レジストリテンプレート。

そのため、構成にオブジェクトを作成することにしました。 やってみましょう。

 $registry = new ArrayObject(); $registry['grabber'] = new Grabber(); $registry['filter'] = new HtmlExtractor(); $registry['google_finder'] = new GoogleFinder($registry['grabber'], $registry['filter']);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ArrayObjectをコントローラーに渡すだけで問題は解決します。

 class Controller { private $registry; public function __construct(ArrayObject $registry) { $this->registry = $registry; } public function action() { /* Some stuff */ $results = $this->registry['google_finder']->find('search string'); /* Do something with results */ } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

レジストリの概念をさらに発展させることができます。 ArrayObjectの継承、新しいクラス内のオブジェクトの作成のカプセル化、初期化後の新しいオブジェクトの追加などを禁止します。 しかし、私の意見では、上記のコードにより、レジストリテンプレートが何であるかを完全に理解することができます。 このパターンはジェネレーターには適用されませんが、ある程度は問題を解決できます。 レジストリは、オブジェクトを格納し、アプリケーション内で転送できる単なるコンテナです。 オブジェクトを使用可能にするには、まずオブジェクトを作成し、このコンテナーに登録する必要があります。 このアプローチの長所と短所を見てみましょう。

一見、目標を達成しました。 クラス名のハードコーディングを停止し、オブジェクトを1か所で作成しました。 オブジェクトを単一のコピーで作成し、再利用を保証します。 オブジェクトの作成ロジックが変更された場合、アプリケーション内の1つの場所のみを編集する必要があります。 ボーナスとして、レジストリ内のオブジェクトを集中管理する機能を受け取りました。 使用可能なすべてのオブジェクトのリストを簡単に取得し、それらを使用して操作を実行できます。 このテンプレートで私たちに合わないものを見てみましょう。

まず、レジストリに登録する前にオブジェクトを作成する必要があります。 したがって、「不要なオブジェクト」を作成する可能性が高くなります。 メモリ内に作成されますが、アプリケーションでは使用されません。 はい、オブジェクトをレジストリに動的に追加できます。 特定の要求を処理するために必要なオブジェクトのみを作成します。 何らかの方法で、これを手動で制御する必要があります。 したがって、時間の経過とともに維持することは非常に困難になります。

次に、新しいコントローラーの依存関係があります。 はい、レジストリをコンストラクタに渡さないように、レジストリの静的メソッドを介してオブジェクトを受け取ることができます。 しかし、私の意見では、これを行うべきではありません。 静的メソッドは、オブジェクト内に依存関係を作成するよりもさらに困難な接続であり、テストが困難です（このトピックに関する優れた記事を参照してください ）。

第三に、コントローラーインターフェースは、使用されているオブジェクトについては何も伝えません。 コントローラーからレジストリで利用可能なオブジェクトを取得できます。 すべてのソースコードをチェックするまで、コントローラーが使用するオブジェクトを正確に言うのは困難です。

工場方式

レジストリでは、オブジェクトを最初に初期化してアクセス可能にする必要があるという事実に最も不快です。 構成でオブジェクトを初期化する代わりに、オブジェクトを作成するロジックを別のクラスに分離し、そこから必要なオブジェクトをビルドするように「依頼」することができます。 オブジェクトの作成を担当するクラスは、ファクトリーと呼ばれます。 そして、設計パターンはファクトリーメソッドと呼ばれます。 ファクトリーの例を見てみましょう。

 class Factory { public function getGoogleFinder() { return new GoogleFinder($this->getGrabber(), $this->getHtmlExtractor()); } private function getGrabber() { return new Grabber(); } private function getHtmlExtractor() { return new HtmlFiletr(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原則として、1つのタイプのオブジェクトの作成を担当するファクトリーが作成されます。 ファクトリは、関連するオブジェクトのグループを作成できる場合があります。 プロパティでキャッシュを使用して、オブジェクトの再作成を回避できます。

 class Factory { private $finder; public function getGoogleFinder() { if (null === $this->finder) { $this->finder = new GoogleFinder($this->getGrabber(), $this->getHtmlExtractor()); } return $this->finder; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファクトリメソッドをパラメーター化し、入力パラメーターに応じて他のファクトリーに初期化を委任できます。 これは、Abstract Factoryテンプレートになります。

アプリケーションをモジュールに分割する必要が生じた場合、各モジュールが独自のファクトリーを提供するように要求できます。 工場のテーマをさらに発展させることはできますが、このテンプレートの本質は明確だと思います。 コントローラーでファクトリーを使用する方法を見てみましょう。

 class Controller { private $factory; public function __construct(Factory $factory) { $this->factory = $factory; } public function action() { /* Some stuff */ $results = $this->factory->getGoogleFinder()->find('search string'); /* Do something with results */ } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチの利点には、そのシンプルさが含まれます。 私たちのオブジェクトは明示的に作成され、あなたのIDEはこれが起こる場所にあなたを簡単に導きます。 また、レジストリの問題も解決しました。メモリ内のオブジェクトは、ファクトリに「問い合わせる」ときにのみ作成されます。 しかし、コントローラーに必要な工場を供給する方法をまだ決定していません。 いくつかのオプションがあります。 静的メソッドを使用できます。 コントローラーに必要なファクトリーを作成させ、コピーと貼り付けをなくすすべての試みを無効にすることができます。 工場の工場を作成し、それだけをコントローラーに転送できます。 しかし、コントローラーでオブジェクトを取得することはもう少し複雑になり、工場間の依存関係を管理する必要があります。 さらに、アプリケーションでモジュールを使用する場合、モジュールファクトリを登録する方法、異なるモジュールからのファクトリ間の通信を管理する方法については、完全に明確ではありません。 一般に、ファクトリの主な利点-オブジェクトの明示的な作成を失いました。 そして、彼らはまだコントローラーの「暗黙の」インターフェースの問題を解決していません。

サービスロケーター

Service Locatorテンプレートを使用すると、工場の断片化の欠如を解決し、オブジェクトの作成を自動的かつ一元的に管理できます。 考えてみると、アプリケーション内でオブジェクトを作成し、これらのオブジェクト間の関係を管理する抽象レイヤーを追加できます。 このレイヤーがオブジェクトを作成できるようにするには、これを行う方法に関する知識を付与する必要があります。

Service Locatorテンプレートの条件：

• サービス（Service）-コンテナから取得できる完成したオブジェクト。
• サービスの説明（サービス定義）-サービスを初期化するためのロジック。
• コンテナ（サービスコンテナ）は、すべての説明を格納し、それらからサービスを作成できる中央オブジェクトです。

どのモジュールでも、サービスの説明を登録できます。 コンテナからサービスを取得するには、キーでリクエストする必要があります。 Service Locatorを実装するための多くのオプションがあります。最も単純なバージョンでは、ArrayObjectをコンテナおよびクロージャーとして、サービスの説明として使用できます。

 class ServiceContainer extends ArrayObject { public function get($key) { if (is_callable($this[$key])) { return call_user_func($this[$key]); } throw new \RuntimeException("Can not find service definition under the key [ $key ]"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、定義の登録は次のようになります。

 $container = new ServiceContainer(); $container['grabber'] = function () { return new Grabber(); }; $container['html_filter'] = function () { return new HtmlExtractor(); }; $container['google_finder'] = function() use ($container) { return new GoogleFinder($container->get('grabber'), $container->get('html_filter')); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、次のようにコントローラーで使用します：

 class Controller { private $container; public function __construct(ServiceContainer $container) { $this->container = $container; } public function action() { /* Some stuff */ $results = $this->container->get('google_finder')->find('search string'); /* Do something with results */ } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サービスコンテナは非常に単純な場合もありますが、非常に複雑な場合もあります。 たとえば、Symfony Service Containerは多くの可能性を提供します：パラメーター、パラメーター、サービスの範囲、タグによるサービスの検索、エイリアス、プライベートサービス、すべてのサービスを追加した後にコンテナーに変更を加える機能（コンパイラパス）など。 DIExtraBundleは、標準実装をさらに拡張します。

しかし、例に戻りましょう。 ご覧のとおり、Service Locatorは以前のテンプレートと同様にこれらの問題をすべて解決するだけでなく、独自のサービス定義でモジュールを簡単に使用できるようにします。

さらに、フレームワークレベルで、追加の抽象化レベルを受け取りました。 つまり、ServiceContainer :: getメソッドを変更することにより、たとえば、オブジェクトをプロキシに置き換えることができます。 また、プロキシオブジェクトの範囲は、開発者の想像力によってのみ制限されます。 ここでは、AOPパラダイム、LazyLoadingなどを実装できます。

しかし、ほとんどの開発者は依然としてService Locatorをアンチパターンと考えています。 理論的には、いわゆる Container Awareクラス（つまり、コンテナーへの参照を含むクラス）。 たとえば、内部で任意のサービスを取得できるコントローラー。

なぜこれが悪いのか見てみましょう。

まず、もう一度テストします。 テストで使用されたクラスに対してのみmokaを作成する代わりに、コンテナ全体に対してmokを実行するか、実際のコンテナを使用する必要があります。 最初のオプションは合わない 2番目のテストでは、不必要なコードをたくさん書く必要があります。 単体テストの原則と矛盾し、テストをサポートするための追加コストにつながる可能性があります。

第二に、リファクタリングすることは困難です。 コンテナ内のサービス（またはServiceDefinition）を変更することにより、すべての依存サービスも強制的にチェックされます。 そして、この問題はIDEを使用して解決されません。 アプリケーション全体でそのような場所を見つけるのはそれほど簡単ではありません。 依存サービスに加えて、コンテナからリファクタリングされたサービスが取得されるすべての場所を確認する必要もあります。

さて、3番目の理由は、コンテナからのサービスの制御されないけいれんが遅かれ早かれ、コードの混乱と不必要な混乱につながることです。 これを説明するのは困難です。特定のサービスがどのように機能するかを理解するためにより多くの時間を費やす必要があります。言い換えると、すべてのソースコードを読むだけでクラスの機能や動作を完全に理解できます。

依存性注入

アプリケーションでコンテナの使用を制限するために他に何ができますか？ コントローラを含むすべてのユーザーオブジェクトの作成に対する制御をフレームワークに渡すことができます。 つまり、ユーザーコードはコンテナのgetメソッドを呼び出さないでください。 この例では、コントローラーの定義コンテナーに追加できます。

 $container['google_finder'] = function() use ($container) { return new Controller(Grabber $grabber); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、コントローラーのコンテナーを取り除きます。

 class Controller { private $finder; public function __construct(GoogleFinder $finder) { $this->finder = $finder; } public function action() { /* Some stuff */ $results = $this->finder->find('search string'); /* Do something with results */ } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチ（サービスコンテナへのアクセスがクライアントクラスに提供されない場合）は、依存性注入と呼ばれます。 しかし、このテンプレートには長所と短所の両方があります。 唯一の責任の原則を順守している限り、コードは非常に見栄えがよくなります。 まず、クライアントクラスのコンテナを削除したため、それらのコードはより理解しやすくなり、よりシンプルになりました。 必要な依存関係を置き換えることで、コントローラーを簡単にテストできます。 TDDまたはBDDのアプローチを使用して、他のクラス（コントローラークラスを含む）から独立して各クラスを作成およびテストできます。 テストを作成するとき、コンテナから抽象化し、後で特定のインスタンスを使用する必要があるときに定義を追加できます。 これにより、コードがよりシンプルでわかりやすくなり、テストがより透明になります。

しかし、コインの裏側に言及する必要があります。 実際、コントローラーは非常に特殊なクラスです。 そもそも、コントローラーには原則として一連のアクションが含まれています。つまり、コントローラーは単独の責任の原則に違反しています。 その結果、コントローラークラスには、特定のアクションを実行するために必要なものよりも多くの依存関係がある場合があります。 遅延初期化の使用（オブジェクトは最初の使用時にインスタンス化され、その前に軽量プロキシが使用されます）により、パフォーマンスの問題がある程度解決されます。 しかし、アーキテクチャーの観点から見ると、コントローラーに多くの依存関係を作成することも完全には正しくありません。 さらに、コントローラーのテストは通常​​、不必要な操作です。 もちろん、すべては、テストがアプリケーションでどのように構成されているか、そしてそれについてあなた自身がどのように感じるかに依存します。

前の段落から、依存性注入を使用してもアーキテクチャの問題が完全になくなるわけではないことに気付きました。 したがって、コンテナーへのリンクをコントローラーに保存するかどうかを考えてみてください。 正しい決定はありません。 コントローラーのコードが単純なままである限り、どちらのアプローチも優れていると思います。 ただし、コントローラー以外にConatiner Awareサービスを作成しないでください。

結論

さて、今は言われたことすべてをノックアウトする時です。 そして、それはたくさん言われました... :)

したがって、オブジェクトの作成作業を構造化するには、次のパターンを使用できます。

• レジストリ ：テンプレートには明らかな欠陥があります。最も基本的なものは、オブジェクトを共通のコンテナに入れる前に作成する必要があることです。 明らかに、それを使用する利点よりも多くの問題が発生します。 これは明らかにテンプレートの最適な使用法ではありません。
• Factory Method ：パターンの主な利点：オブジェクトは明示的に作成されます。 主な欠点：コントローラー自体は、ハードコードクラス名の問題を解決しないファクトリーの作成を心配する必要があります。または、フレームワークは、コントローラーに必要なすべてのファクトリーを提供する責任があります。 オブジェクトを作成するプロセスを集中管理することはできません。
• Service Locator ：オブジェクトの作成を制御する、より「高度な」方法。 追加の抽象化レベルを使用して、オブジェクトの作成時に発生する一般的なタスクを自動化できます。 例：
  
  

   class ServiceContainer extends ArrayObject { public function get($key) { if (is_callable($this[$key])) { $obj = call_user_func($this[$key]); if ($obj instanceof RequestAwareInterface) { $obj->setRequest($this->get('request')); } return $obj; } throw new \RuntimeException("Can not find service definition under the key [ $key ]"); } }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  Service Locatorの欠点は、クラスのパブリックAPIが情報提供を停止することです。 どのサービスが使用されているかを理解するには、すべてのクラスコードを読む必要があります。 コンテナ参照を含むクラスはテストが困難です。
• Dependency Injection : Service Container, . , . , API .

PHPアプリケーションでオブジェクトを作成する問題についてお話したいのはこれだけではありません。また、Prototypeパターンもあります。ReflectionAPIの使用を考慮していません。サービスの遅延読み込みの問題やその他の多くのニュアンスを残しました。この記事は小さくありませんでしたので、詳しく説明します:)

依存性注入やその他のパタ​​ーンは、一般に信じられているほど複雑ではないことを示したかったのです。

依存性注入について説明する場合、このパターンのKISS実装があります。たとえば、コメントとともに数百行しか使用しないPimpleなどがあります。そして、Symfony Dependency Injection Componentのようなモンスターがいます。基本的な原則は同じですが、機能のセットは比較できません。

さて、それがおもしろくて、記事を読むのに時間を費やしたことは無駄ではなかったと思います。



楽しんでください！



PS時間を割いて私のリクエストに応えてくれた皆さん、どうもありがとう。私はあなたの意見を知ることが重要でした;）