依存性注入とシングルトンデザインパターン

Question 1

依存性注入またはシングルトンパターンをいつ使用するかをどのように識別しますか。「シングルトンパターンよりも依存性注入を使用する」と書かれている多くのWebサイトを読んだことがあります。しかし、私がそれらに完全に同意するかどうかはわかりません。私の中小規模のプロジェクトでは、シングルトンパターンの使用は間違いなく簡単です。

たとえば、ロガー。使用できますLogger.GetInstance().Log(...) が、これの代わりに、作成したすべてのクラスにロガーのインスタンスを挿入する必要があるのはなぜですか？

Question 2

テストに何が記録されるかを確認したい場合は、依存性注入が必要です。さらに、ロガーがシングルトンになることはめったにありません。通常、クラスごとにロガーがあります。

テスト容易性のためのオブジェクト指向設計に関するこのプレゼンテーションを見ると、シングルトンが悪い理由がわかります。

シングルトンの問題は、特にテストでは、予測が難しいグローバル状態を表すことです。

オブジェクトは事実上のシングルトンである可能性がありますが、それでもSingleton.getInstance()。ではなく依存性注入を介して取得されることに注意してください。

MiskoHeveryのプレゼンテーションで重要なポイントをいくつか挙げています。それを見た後、依存関係が何であるかをオブジェクトに定義させる方が良い理由について完全な見通しを得ることができますが、それらを作成する方法を定義することはできません。

Question 3

シングルトンは共産主義のようなものです。どちらも紙の上では素晴らしいように聞こえますが、実際には問題が発生して爆発します。

シングルトンパターンは、オブジェクトへのアクセスのしやすさを不釣り合いに強調します。すべてのコンシューマーがAppDomainスコープのオブジェクトを使用することを要求することにより、コンテキストを完全に回避し、さまざまな実装のオプションを残しません。インフラストラクチャの知識をクラスに組み込み（への呼び出しGetInstance()）、表現力をまったくゼロにします。1つのクラスで使用される実装を、すべてのクラスで変更せずに変更することはできないため、実際には表現力が低下します。1回限りの機能を追加することはできません。

また、クラスがにFoo依存しているLogger.GetInstance()場合、Fooはその依存関係をコンシューマーから効果的に隠しています。これは、Fooそのソースを読んで、それがに依存しているという事実を明らかにしない限り、それを完全に理解したり、自信を持って使用したりできないことを意味しますLogger。ソースがない場合は、依存しているコードを十分に理解して効果的に使用できるかどうかが制限されます。

静的プロパティ/メソッドで実装されたシングルトンパターンは、インフラストラクチャの実装に関するハックにすぎません。それは無数の方法であなたを制限しますが、代替案に対して認識できる利益を提供しません。好きなように使用できますが、より良いデザインを促進する実行可能な代替手段があるため、推奨される方法ではありません。

Question 4

他の人は、一般的なシングルトンの問題を非常によく説明しています。Loggerの特定のケースについてのメモを追加したいと思います。静的getInstance()またはgetRootLogger()メソッドを介して、シングルトンとしてロガー（正確にはルートロガー）にアクセスすることは通常問題ではないことに同意します。（テストしているクラスによって何がログに記録されるかを確認したい場合を除きますが、私の経験では、これが必要だったケースを思い出すことはほとんどできません。また、他の人にとっては、これはより差し迫った懸念事項かもしれません）。

IMOには通常、テストしているクラスに関連する状態が含まれていないため、シングルトンロガーは心配ありません。つまり、ロガーの状態（およびその可能な変更）は、テストされたクラスの状態にはまったく影響しません。したがって、ユニットテストがこれ以上難しくなることはありません。

別の方法は、コンストラクターを介して、アプリ内の（ほぼ）すべてのクラスにロガーを挿入することです。代わりにあなたがいることをいくつかの点で発見したときにということでしょう-インタフェースの一貫性を保つため、問題のクラスは、現時点では何もログインしていない場合でも、注入されるべきで、今ので、あなたがこのクラスから何かをログに記録する必要がある、あなたはロガーを必要としますDIのコンストラクターパラメーターを追加して、すべてのクライアントコードを壊す必要があります。私はこれらのオプションの両方が嫌いであり、ロギングにDIを使用することは、具体的なメリットなしに、理論的なルールに準拠するために私の人生を複雑にするだけだと感じています。

つまり、私の結論は次のとおりです。（ほぼ）普遍的に使用されているが、アプリに関連する状態を含まないクラスは、シングルトンとして安全に実装できます。

Question 5

それはほとんどですが、テストについては完全ではありません。シングルトンは使いやすいという理由で人気がありましたが、シングルトンにはいくつかの欠点があります。

テストするのは難しい。ロガーが正しいことをすることをどのように確認するかという意味です。
テストするのは難しい。つまり、ロガーを使用するコードをテストしているが、それがテストの焦点ではない場合でも、テスト環境がロガーをサポートしていることを確認する必要があります
シングルトンが必要ない場合もありますが、柔軟性が高くなります

DIを使用すると、依存クラスを簡単に使用できます。コンストラクター引数に入れるだけで、システムが提供しますが、テストと構築の柔軟性も提供します。

Question 6

依存性注入の代わりにシングルトンを使用する必要があるのは、シングルトンがList.Emptyなどの不変の値を表す場合だけです（不変のリストを想定）。

シングルトンのガットチェックは、「これがシングルトンではなくグローバル変数であったとしても大丈夫でしょうか？」である必要があります。そうでない場合は、シングルトンパターンを使用してグローバル変数を処理しているため、別のアプローチを検討する必要があります。

Question 7

モノステートの記事をチェックしてください-これはシングルトンの気の利いた代替手段ですが、いくつかの奇妙な特性があります：

class Mono{
    public static $db;
    public function setDb($db){
       self::$db = $db;
    }

}

class Mapper extends Mono{
    //mapping procedure
    return $Entity;

    public function save($Entity);//requires database connection to be set
}

class Entity{
public function save(){
    $Mapper = new Mapper();
    $Mapper->save($this);//has same static reference to database class     
}

$Mapper = new Mapper();
$Mapper->setDb($db);

$User = $Mapper->find(1);
$User->save();

マッパーはsave（）を実行するためにデータベース接続に実際に依存しているため、この種の恐ろしいことではありませんが、別のマッパーが以前に作成されている場合は、依存関係を取得する際にこのステップをスキップできます。きちんとしていますが、それもちょっと面倒ですよね？

Question 8

シングルトンには他にもプロキシパターンとモノステートパターンがあります。

http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf

プロキシパターンを使用してシングルトンを置き換えるにはどうすればよいですか？