シングルトンが悪い場合、サービスコンテナはなぜ良いのでしょうか。

我々は、すべての方法を知っている悪いシングルトン彼らは依存関係を非表示にするためにためている他の理由。

しかし、フレームワークでは、一度だけインスタンス化してどこからでも呼び出す必要のある多くのオブジェクト（ロガー、dbなど）が存在する可能性があります。

この問題を解決するために、サービス（ロガーなど）へのすべての参照を内部的に保存する、いわゆる「オブジェクトマネージャー」（またはsymfonyのようなサービスコンテナー）を使用するように言われました。

しかし、サービスプロバイダーが純粋なシングルトンほど悪くないのはなぜですか？

サービスプロバイダーも依存関係を隠し、最初のインスタンスの作成をラップアウトするだけです。そのため、シングルトンの代わりにサービスプロバイダーを使用する理由を理解するのに本当に苦労しています。

PS。依存関係を隠さないようにするには、DIを使用する必要があることを知っています（Miskoが述べたように）

追加

私は付け加えます：最近のシングルトンはそれほど悪ではありません、PHPUnitの作成者はここでそれを説明しました：

• http://sebastian-bergmann.de/archives/882-Testing-Code-That-Uses-Singletons.html

DI +シングルトンは問題を解決します：

<?php
class Client {

    public function doSomething(Singleton $singleton = NULL){

        if ($singleton === NULL) {
            $singleton = Singleton::getInstance();
        }

        // ...
    }
}
?>

これですべての問題が解決されなくても、それはかなりスマートです。

DIとService Container以外に、このヘルパーオブジェクトにアクセスするための適切なソリューションはありますか？

言うまでもなく、Service Locatorは2つの悪の小さい方です。これらの4つの違いへの「より少ない」沸騰（少なくとも、今のところ他のものを考えることはできません）：

単一責任の原則

サービスコンテナは、シングルトンのように単一責任の原則に違反していません。シングルトンはオブジェクトの作成とビジネスロジックを混合しますが、サービスコンテナはアプリケーションのオブジェクトライフサイクルの管理に厳密に責任があります。その点では、サービスコンテナの方が優れています。

カップリング

シングルトンは通常、静的メソッド呼び出しのためにアプリケーションにハードコードされます。これにより、コードの依存関係が密結合になり、モック化が困難になります。一方、SLは1つのクラスにすぎず、挿入できます。したがって、すべてのクラスはそれに依存しますが、少なくとも疎結合の依存関係です。したがって、ServiceLocatorをシングルトン自体として実装しない限り、それは多少優れており、テストも簡単です。

ただし、ServiceLocatorを使用するすべてのクラスは、結合の形式であるServiceLocatorにも依存するようになります。ServiceLocatorのインターフェースを使用することでこれを軽減できるため、具体的なServiceLocator実装にバインドされませんが、クラスは何らかの種類のLocatorの存在に依存しますが、ServiceLocatorをまったく使用しないと、再利用が大幅に増加します。

非表示の依存関係

ただし、依存関係を非表示にする問題は非常に深刻です。ロケーターを使用するクラスに挿入するだけでは、依存関係はわかりません。ただし、シングルトンとは対照的に、SLは通常、背後で必要なすべての依存関係をインスタンス化します。そのため、サービスをフェッチするとき、CreditCardの例ではMisko Heveryのようにはなりません。たとえば、依存関係のすべての依存関係を手動でインスタンス化する必要はありません。

インスタンス内から依存関係を取得することも、デメテルの法則に違反しており、コラボレーターを掘り下げるべきではないと述べています。インスタンスは直接の共同編集者とのみ会話する必要があります。これは、シングルトンとServiceLocatorの両方の問題です。

グローバルステート

テスト間で新しいService Locatorをインスタンス化すると、以前に作成されたすべてのインスタンスも削除されるため、グローバル状態の問題も多少緩和されます（間違いを犯してSLの静的属性に保存した場合を除く）。もちろん、SLが管理するクラスのグローバル状態には当てはまりません。

さらに詳しい説明については、サービスロケーターと依存性注入の Fowlerも参照してください。

シングルトンを使用するコードのテストに関する更新とSebastian Bergmannによるリンクされた記事に関するメモ：Sebastianは、提案された回避策がシングルオンの使用の問題を軽減することを決して示唆していません。これは、他の方法ではテストをよりテストしにくいコードを作成するための1つの方法にすぎません。しかし、それでも問題のあるコードです。実際、彼は明確に次のように述べています。

サービスロケーターパターンはアンチパターンです。依存関係を公開する問題は解決しません（クラスの定義を見ても、依存関係が注入されていないため、サービスロケーターからヤンクされているため、依存関係はわかりません）。

それで、あなたの質問は、なぜサービスロケーターが良いのですか？私の答えは、そうではありません。

避ける、避ける、避ける。

シングルトンパターンのように、サービスコンテナーは依存関係を非表示にします。依存関係注入コンテナを使用することをお勧めします。サービスコンテナにはすべての利点がありますが、サービスコンテナには（私の知る限り）欠点はありません。

私が理解している限り、2つの唯一の違いは、サービスコンテナーでは、サービスコンテナーが注入されるオブジェクトであるため（依存関係を非表示にする）、DICを使用すると、DICが適切な依存関係を注入します。DICによって管理されているクラスは、DICによって管理されているという事実を完全に認識していないため、結合が少なく、依存関係が明確で、ユニットテストが円滑になります。

これは、SOの両方の違いを説明する良い質問です。依存性注入とサービスロケータパターンの違いは何ですか？

Service Container内のオブジェクトを
1）継承（Object Managerクラスは継承でき、メソッドをオーバーライドできる）で簡単に置き換えることができるため、
2）構成の変更（Symfonyの場合）

そして、シングルトンは結合が高いためだけでなく、それらが_ シングル _tonであるために悪いです。ほとんどすべての種類のオブジェクトにとって、これは間違ったアーキテクチャです。

「純粋な」DI（コンストラクター内）を使用すると、非常に高額な料金が発生します。すべてのオブジェクトは、コンストラクターに渡される前に作成する必要があります。メモリの使用量が増え、パフォーマンスが低下します。また、常にオブジェクトを作成してコンストラクタに渡すだけではない-依存関係のチェーンを作成できる...私の英語はそれについて完全に議論するには十分ではありません。Symfonyのドキュメントで読んでください。

私は、単純な理由でグローバル定数やシングルトンを避けようとしています。APIを実行する必要がある場合があります。

たとえば、フロントエンドと管理者がいます。admin内では、ユーザーとしてログインできるようにしたいと考えています。admin内のコードを検討してください。

$frontend = new Frontend();
$frontend->auth->login($_GET['user']);
$frontend->redirect('/');

これにより、フロントエンドの初期化用に新しいデータベース接続、新しいロガーなどが確立され、ユーザーが実際に存在するか、有効かどうかが確認されます。また、適切な個別のCookieと位置情報サービスが使用されます。

シングルトンについての私の考えは、親の中に同じオブジェクトを2回追加することはできません。例えば

$logger1=$api->add('Logger');
$logger2=$api->add('Logger');

単一のインスタンスとそれを指す両方の変数を残します。

最後に、オブジェクト指向の開発を使用する場合は、クラスではなくオブジェクトを操作します。