重複の可能性：
シングルトン：どのように使用する必要がありますか
Ewan Makepeaceのシングルトンパターンに関する以前の優れた質問に続いて、「コミュニティはいつシングルトンを使用することが適切であると信じているのか」と尋ねると思いました。
批評の例を挙げましょう。
「IconManager」シングルトンがあります。まず、アイコンがディスク上のどこにあるかを示すプロパティファイルを読み取り、次にすべてのアイコンを読み取り、将来の使用のためにキャッシュします。
アイコンはUI全体（タブ、テーブル、フレームなど）で使用できます。したがって、静的なシングルトンメソッドを介してアイコンにアクセスするのは非常に便利です。また、アイコンが1回だけ読み取られるようにしたい（必要になるたびにディスクからアイコンを読み取るのが非常に遅い場合）コミュニティは、これがシングルトンの適切な使用法であると信じていますか？そうでない場合、他にどのように実装されている可能性がありますか？
シングルトンの他の有効な使用法はありますか？
別のアプローチは、アイコンをロードするクラスのインスタンスを作成してから、このインスタンスへの参照を、リソースにアクセスする必要のあるすべてのコントロールに渡すことです。そうすれば、将来的には複数のアイコンローダーを使用して、必要に応じてそれらを渡すことができます。将来に向けてより柔軟になりますが、参照を無数のコントロールに渡すことができるというかなり大きな欠点があります。
IconManagerはファクトリパターンを実装し、アイコンを作成します。また、アイコンを作成するために必要なファクトリはおそらく1つだけです。したがって、この場合、シングルトンIMHOを使用しても問題はありません。私はこれらの一元化された工場のいくつかでソフトウェアを構築しましたが、すべてがうまくいきました。
このスレッドも参照してください：シングルトンクラスの誤用の最も一般的な例
シングルトンの適切な使用法は、アクティブな接続が 1 つしかないリソースにアクセスする場合です。この制限を持つ多くのハードウェア デバイスがあります。
1 つの接続のみを許可するCCTV カメラに接続しているとします。Singleton パターンは、最初の使用時にこの接続を作成し、開いたままにします。おそらく複数のソースからのカメラからの写真が必要なときはいつでも、他の問題を考慮して、写真が利用可能になることを知ってシングルトンをヒットできます。
カメラの初期接続時間も遅い場合は、接続を開くのではなく、この方法で接続を開いたままにし、写真を取得して再度接続を閉じる方がはるかに効率的です.
私は実際にシングルトンを使用したことはありませんが、デザインパターンはあまり使用していません。ファクトリーやゲートウェイのパターンのように、他のパターンがそれらを必要とする場合、それらは非常に価値があると思います。しかし、それらがすべて単独で良いことはほとんどありません。
多くの欠点がなく、シングルトンのすべての利点を提供するモノステートパターンを検討することをお勧めします。これにより、探しているグローバルプロパティをたまたま持っている状態のリッチオブジェクトを作成することもできます。