サービスロケータはグローバル変数/状態だけではありませんか？

Question

コードをデカップリングするには、サービスロケータを持つことができますが、これはグローバル変数/状態と同じではありませんか？

私はこれらのインターフェイスが頻繁に実行されることを知っていますので、インターフェイスを渡して具体的なクラスを取得することができます。例えば

：

class Something { 

    void DoSomething() { 
     IMyType myType = ServiceLocator.GetSerivceTypeOf(IMyType); 
    } 
} 

ここ

クラスはどこかに作成したのではなく、それは、このように取得された（...を経由して、コンストラクタなど）チェーンを通じてダウンがMy​​Typeを渡すよりもされたがMyTypeが必要です。

_{私はこの質問を開発者として私のプロとしてのキャリアの初期に尋ねました。その前に私はこのパターンに遭遇しませんでした。 Anthonyはサービスロケータの意見に私の意見を釘付けにしました（そして、今や選択された答えです）。実際、私はそれらを他者のような反パターンと見ています。提供されたリンクは良い出発点ですが、この後も私自身の質問にいくらか答えなければならないので、彼らはグローバルな国家として行動し、避けるべきです。 ）標準的な依存性注入を推奨する。}

Answer 1

はいこれらはグローバル変数です。洗練されたものですが、まだ同じ基本的な欠点があります。そのため、依存性注入が好ましい。コンストラクタ・インジェクションの代替のより詳細な議論については

、質問What’s the difference between the Dependency Injection and Service Locator patterns?

そして、他のウェブページSingletons are Pathological LiarsとDependency Injection pattern

Answer 2

通常、サービスロケータパターンをバックアップするネームサービスは、実際にはグローバルな名前空間を使用する。

しかし、「グローバル変数」が悪いとみなされる理由を考慮する必要があります。これらの多くは、プログラムのどこにいてもグローバル変数を変更する機能を中心に展開されています。ただし、ほとんどのネーミングサービスでは、バインドされたオブジェクトの変更を制限できます。オブジェクト自体は不変であってもよい。

サービスロケータは単にグローバル変数ではなく、特殊化されています。その特化は、グローバル変数から生じる可能性のある問題の多くを緩和する傾向があります。

Answer 3

いくつかの作業を行うには具体的な実装が必要です。このサービスは、アプリケーションに「利用可能」という意味で「グローバル」です。しかし、コード内でグローバル変数にする必要はありません。

引数を逆にすることができます。アプリケーションのサービスにアクセスする必要がある場合、そのアプリケーションにアクセスするためにどのパターンを使用し、具体的な実装にバインドする必要はありません。多くの選択肢はありません。

一部のリソースは、議論は一つ問題解決よりも哲学的な一つであり、オペレーティングシステム、ファイルシステム、ウィンドウシステム、...

を取る、あなたのアプリケーションに対して本質的に「グローバル」です。とにかく、それが助けて欲しい。