DIとサービスロケータは、いずれもオブジェクトの構築と依存の解決という仕事を切り出すためのパターンです。ところで、この2つのパターンの違いを明確に説明できるでしょうか？

Pimpleでシンプルに正しくDIを理解する のコードは以下のようになっていました。

<?php require_once '../vendor/pimple/pimple/lib/Pimple.php'; // インフラ interface MailerInterface { public function send($body); } class SendmailMailer implements MailerInterface { public function send($body) { } } // ドメイン class NewsletterTransfer { protected $mailer; public function __construct(\MailerInterface $mailer) { $this->mailer = $mailer; } public function send($newsletter) { $this->mailer->send($newsletter); } } $container = new \Pimple(); // オブジェクトコンストラクションのコンフィギュレーション $container['infrastructure.mailer'] = function($container) { $mailer = new \SendmailMailer(); return $mailer; }; $container['domain.transfer.newsletter'] = function($container) { $newsletterTransfer = new \NewsletterTransfer($container['infrastructure.mailer']); return $newsletterTransfer; }; // オブジェクトの利用 $newsletterTransfer = $container['domain.transfer.newsletter']; $newsletterTransfer->send('ニュースレター本文');

DIの仕組みを解説するためのこのコードには、実は、DIパターンとサービスロケータパターンとが混在しています。このコードから、オブジェクトごとのまとまりを意識してパーツを取り出すと、次の3つになります（利用側から順に並べています）。

<?php // オブジェクトの利用 $newsletterTransfer = $container['domain.transfer.newsletter']; $newsletterTransfer->send('ニュースレター本文');

<?php // ドメイン class NewsletterTransfer { protected $mailer; public function __construct(\MailerInterface $mailer) { $this->mailer = $mailer; } public function send($newsletter) { $this->mailer->send($newsletter); } }

<?php // インフラ class SendmailMailer implements MailerInterface { public function send($body) { } }

図にすると、次のようになります。

どこがDIで、どこかサービスロケータなのでしょうか？ また、この3つのオブジェクトの仲介役として機能するコンテナは、DIコンテナなのでしょうか？サービスロケータ（の対象コンテナ）なのでしょうか？

オブジェクトから見たコンテナの位置づけ

DIなのかサービスロケータなのか、この2つの違いを明確にするには、オブジェクトがコンテナに何を求めているのかを理解しなくてはなりません。

必要なオブジェクトをコンテナから取り出す（能動的）

上のコードの入口部分にあたる「オブジェクトA」をAさんが開発しているとしましょう。Aさんの視点だけをピックアップしたのが次の図です。

オブジェクトBやオブジェクトCの開発はAさんの担当ではありません。オブジェクトBがどのように構築されるのかは、コンテナに定義されているため、Aさんは単にコンテナからオブジェクトAを取り出して、使うだけです。

オブジェクトAからは、コンテナを直接参照し、名前をキーにして使いたいオブジェクトを取り出します。

オブジェクトBがどのように作られるのかを気にすることなく、完成し たオブジェクトBをただ使うという目的を達成するために、コンテナから名前をキーにしてオブジェクトを取り出す、これがサービスロケータのパターンです。

オブジェクトAは、コンテナの外側でインスタンス化されます。コンテナの管理下にないこのようなオブジェクトでは、直接コンテナオブジェクトを道具として参照して使う必要があるわけです。たとえばSymfony Standard Editionに標準で用意されているコントローラクラスはコンテナの管理下にないため、サービスロケータ方式になっています。

必要なオブジェクトの受け口だけ用意して受け取る（受動的）

別の担当者Bさんは、オブジェクトBを開発しています。Bさんの視点だけをピックアップしたのが次の図です。

オブジェクトBの実装には、オブジェクトC（のインターフェイス）を使っています。このオブジェクトCは、さらにD、E・・・を使っているかもしれませんが、オブジェクトCから先はBさんの担当ではありません。ただ単にオブジェクトCを使い、自分の担当であるオブジェクトBの処理を実装したいだけです。

このプロジェクトでは、オブジェクトBは、必ずコンテナ経由で利用する、という取り決めがあると思ってください。つまり、オブジェクトBはコンテナの管理下にあるわけです。このような場合、オブジェクトBの生成時に、コンストラクタの引数や追加のセッター呼び出しによって、必要な依存オブジェクトをコンテナが自動的にセットするようにできます。オブジェクトBは、「受け取る道具の種類」をコンストラクタの引数で示してはいますが、自ら取り出しているわけではありません。

オブジェクトCがどのように作られるのかを気にすることなく、完成したオブジェクトCをただ使うという目的を達成するために、使いたいオブジェクトの受け取り口だけ用意して、コンテナがそこへ渡してくれる、というのがDIのパターンです。

まとめ

同じコンテナでも、それを使うオブジェクトがコンテナの管理下にあるかどうかで、使える手法が異なります。プロジェクトで利用するフレームワークとの兼ね合いで、コンテナ管理下におけない状況などがあります。

重要なのは、DIでもサービスロケータでも、依存の解決とオブジェクトの構築という仕事をオブジェクト自身からコンテナへ移しているのは同じだということです。これによって、Aさん、Bさんはそれぞれの担当範囲のみに集中できます。オブジェクトのコードから余計なものが取り除かれ、自分の仕事により局所化されるようになります。

参考

PHPメンターズ道場生 kumamidori です。 PHPのエキスパートとして世界的に知られている方の１人に、Paul M. Jonesさんがいらっしゃいます。 フレームワーク「Aura for PHP」のリードであり、PHP-FIGの策定メンバーに入られている方です。 通称 pmjones さんのブログで、昨年末、DIに関する下記エントリがありました。 「Quicker, Easier, More Seductive: How To Tell A DI Container From A Service Locator」 興味深い内容のようだったので、翻訳しました。翻訳記事の公開について、著者ご本人から快諾頂けたため、掲載させて頂きます。 本文中にあるとおり、この記事に対する訂正として、「Quicker, Easier, More Seductive: Names, Usage, and Intent」という記事がありますので、併せてご確認下さい。 記事の内容について、皆様はどのように感じられるでしょうか。人によって、同意や疑問等、いろいろあるのではないかと想像します。

速く、簡単に、もっときれいに： DIコンテナとサービスロケータを区別する方法について

2013年12月16日 pmjones

（このふいに始まったシリーズでは、 サービスロケータ対 Dependency Injection について語ってきました）。 更新情報： このシリーズの次の記事で、重要な訂正をしています。 また、この記事の後半については、後から追記を加えました。併せてご確認下さい。 DIコンテナとサービスコンテナは混同しがちです。両者はよく似ています。たしかにほとんど違いがありません。 DIコンテナをサービスロケータとして使うこともできます。 しかし、DIコンテナとしてサービスロケータを使うことは難しいと私は考えています。 両者とも、制御の反転（Inversion of Control）と呼ばれている、一般的なパターンのサブパターンです。 用語として、 Dependency Injectionを、より一般的な用語である制御の反転（Inversion of Control）と混同する人がいます。

違いをどう説明したら良いか

どういったルール、目安によって、どっちがどっちなのかを易しく判別できるか、検討しました。 今のところ、「新しいインスタンスを、サービスを定義することなく生成できるか？」だと考えています。 生成できるのであれば、それはDIコンテナ。 そうでなければ、それはサービスロケータです。 このフレーズには、いくつかバリエーションがあります：

クラスの新しいインスタンスを、サービス定義を持つことなしに、生成できるのならば、それはDIコンテナです。

コンテナの外でオブジェクトを取得するのに、サービスを定義する必要があるのならば、それはサービスロケータです。

クラスの新しいインスタンスを、サービスとしてそれを定義することなく生成することができないのであれば、それはサービスロケータです。

これによって私は、コンテナで、サービスとしてインスタンス定義を持つことなく、新しい、個々の、独立したクラスのインスタンスを繰り返し生成することができるべきだと言おうとしているわけです。

例

上記のルールを踏まえた上で、例として、Aura.DIを使った Dependency Injection のサンプルを示します。

// これらは別々のインスタンスであり、サービスを共有していません $foo_1 = $di->newInstance('Foo\Bar\Baz'); $foo_2 = $di->newInstance('Foo\Bar\Baz'); var_dump($foo_1 === $foo_2); // false

コンストラクタパラメータの設定や、セッタなどが要るかもしれません。 newInstance() を呼び出しする時のために？そうです。 Aura.DI は、コンストラクタパラメータやセッタメソッドの継承や上書きができるようになっています。

// __construct($gir) として与えられます $di->params['Foo\Bar\Baz']['gir'] = $di->newInstance('Dib\Zim\Gir'); // セッタメソッドとして setOperation($operation_name) が与えられます $di->setter['Foo\Bar\Baz']['setOperation'] = 'ImpendingDoom';

要点は、DIコンテナはいつでもクラスを作ることができて、 再利用されるサービスとしてクラスの定義を持つことはなくできるということです。 一方、サービスロケータは、サービスとしての定義を必要とします。 そして、コンテナからサービスの共有インスタンスを取得することができます。 このシリーズの初期の方からよくある私のサービスロケータの例を示します。

// 共有されるサービスを定義する $locator->set('gir', function () use ($locator) { return new \Dib\Zim\Gir; } $locator->set('foo', function () use ($locator) { $foo = new \Foo\Bar\Baz($locator->get('gir')); $foo->setOperation('ImpendingDoom'); return $foo; }); // これらは共有されているサービスで、インスタンスは分離していません $foo_1 = $locator->get('foo'); $foo_2 = $locator->get('foo'); var_dump($foo_1 === $foo_2); // true

誰が何をやっているか？

このルールを満たしているかどうか確かめようと、PHP界におけるコンテナをいくつかちょっと見てみました。 私が調べたのは下記です。

Aura.Di: DIコンテナ

Laravel Container: サービスロケータ　DIコンテナ

Pimple (Silex などで使われている): サービスロケータ

Slim (via $app): サービスロケータ

Symfony DependencyInjection component: サービスロケータ (?!)

Zend Di: DIコンテナ

分かったこと：

Laravel:

ドキュメントでは、コンテナをIoC（制御の反転）コンテナと呼んでいます。 しかし、一貫して Dependency Injection について言及されています。決してサービスロケータとは言っていません。 コンテナの使い方を見ると、サービスを必要とするクラスに、コンテナそれ自身がインジェクトされるために、 あとのコードベースはすべて事実上サービスロケータであることは明らかです。 クラス自体は一般的な方にネーミングされているから、ドキュメントの方を修正すれば良いことに気づきました。

追記：

プロジェクトリードから、コンテナの public make() メソッドは、新しいインスタンスを生成できると私に連絡がありました。 細かいことを言わせて頂くなら、ネーミングが余計なのだけれども （私見ですが、$abstract や make() ではなくて、 $class や newInstance() を使う方がわかりやすいでしょう）、 前述のルールについては満たしています。

Pimple:

おもしろいことに、Pimpleは、独立したサービスのインスタンスを返すfactoryメソッドを持っています。 先ほどのルールをクリアしていると思う人がいるかもしれませんが、私はそうは思いません。 結局、まだサービスの定義が必要になっているからです。 特定のクラス名のために、ファクトリとしてサービスを定義するかもしれないし、 ファクトリされたクラスのためにサービスを命名するかもしれませんけれど、 この、ファクトリがほしいクラスのためにサービスを定義する必要があるということから、本当に同じとは言えないと思います。

Slim:

$app をサービスロケータとして使っています。 分かっていて、Josh Lockhart はサービスロケータともDIコンテナとも言っていません。 @codeguy はこの話題を両方避けていてさすがです。

Symfony DependencyInjection component:

コードベースを私が少し見たところ、クラスのインスタンスを生成する方法が明らかではありませんでした。 機能が無いのではなくて、私がまだ見つけられていないだけの可能性が高いです。 Symfony使いさんがこれを読んでいたら、私に教えて下さい。Symfony DI component でどうやってクラスのインスタンスを生成するのか。 そうしたら、この記事をアップデートします。

結論

ルールに照らし合わせてみると、Dependency Injection システムだと言っているものの一部は、サービスロケータとして説明する方が適切でした。 一般的には、コンテナ（制御の反転 Inversion of Control コンテナ）かもしれないけれど、それはDIコンテナではありません。 DIコンテナでないことが間違っているのではなくて、 これらを間違った名前で使っていることで、話が混乱して、複雑になってしまうのです。

1. ポールがどんなルールを作ろうが、ある種の人たちが好きなシステムは本当にDIコンテナなのだ

2. そんな区別は実際大した問題ではない。どうなっていようが、好きなシステムを使えば良いだけだ。

コメントお待ちしております:-)

後書き