2012-03-15 10 views
9

現在、私のZend FrameworkベースのPHPライブラリは、サービスロケータから(コンストラクタ)依存性注入(DI)を使用してリファクタリングしています。私はそれが私のコードを大幅に改善すると感じますが、私はすべての依存関係を注入する必要があるかどうかはわかりません。サービスロケータは、多く使用されている非特定の依存関係の方が簡単です。私はまだサービスロケータを使用してアクセスしている次の依存関係を持っています:依存性注入:いくつかのオブジェクトにすべてを注入するか、サービスロケータを使用する必要がありますか?

  1. Zend_Translateオブジェクト(私はどこでもメッセージを翻訳する必要があります)。
  2. A Zend_Localeのオブジェクト(店舗現在の言語)
  3. A(配列と文字列操作のための)ユーティリティクラスのZend_Configオブジェクト(物事の多くは、INIファイルによって設定されている)
  4. インスタンス

これらの依存関係を挿入すると、コンストラクタが混乱し、特定の依存関係から気をそらすことになります。テストのために、テストを実行する前にサービスロケータでこれらの依存関係を設定することができます。私の中の実践主義者は、私はうまくやっていると言いますが、純粋主義者は私がDIでいっぱい進むべきだと言います。

これらのタイプのオブジェクトにDIを使用するかどうかをお教えしますか?

+3

にはお答えできません。あなたは明らかに賛否両論があることを知っています。意識的な決定を下すことは、あなた次第です。 – Gordon

+0

さて、問題は、DIを推奨するのかそうでないのかを教えてください。その意味での質問は明らかです。 – markus

+0

私はupvoteと閉じるために投票する非常に少数の質問があります。それは素晴らしい質問ですが、あなたの心をつくるのはあなた次第です。それはあなたのアプリケーションであり、あなたはその主題の賛否両論を知っています。 –

答えて

18

コンストラクタの混乱が懸念される場合は、a code smell that the classes are violatingSingle Responsibility Principleの可能性が最も高いです。コンストラクターの注入は、これをはるかに明白にするため、ここで非常に有益です。

稀にしか使用されない依存関係の注入についても心配している人もいますが、that's not a problem eitherです。オブジェクトグラフの作成に関しては、パフォーマンスが問題になることはほとんどありません。たとえそうであったとしても、バーチャルプロキシパターンはそれを修正できます。

要するに、Service Locatorを使用する理由はありません。コントロールの適切な逆転を含むより良い選択肢が常にあります。

+2

に記載されている理由から、@ markus。しかし、サービス・ロケータを使用することが依存性反転を行う唯一の方法である状況があります。たとえば、依存関係注入をサポートしていない第三者フレームワークによってクラスがインスタンス化されている場合などです。 –

関連する問題