このサイトでは、シングルトンを避ける必要がある理由について多くの議論がありますが、シングルトンが理にかなっていて最良の選択肢である場合はありますか？
シングルトンが最良のオプションであると私が考える例は、マッピング層のデータベースからすでにロードされているすべてのモデルを追跡する必要があるIDマップを実装する場合です。この場合、すべてのクライアントコードがマップの同じインスタンスを使用し、ロードされたモデルの同じリストにすべてアクセスできるように、マップが事実上グローバルであることが重要です。最も簡単な解決策は、クラスをシングルトンとして（または静的メソッドとして）実装することのようです。これが最善のアプローチですか、それとも別の方法がありますか？
シングルトンを使用しても問題がない場合や、常に悪い場合は他にありますか？
このスレッドを参照してください。
シングルトンには確かに用途があります。それらの有用性を次のように要約します。
「シングルトンは、基本的な設計または要件に従って、最大で 1 つのインスタンスが存在できるオブジェクトを表すために使用する必要があります。また、測定可能なコストが発生するオブジェクトに関連付けられたデータまたはリソースがあります。」これが私の言いたいことです。
1）何かがたくさんある場合にシングルトンを使用するべきではありませんが、たまたま1つだけに興味があります。システムに 2 つ存在する可能性がある場合は、1 つを明示的にインスタンス化します。
2) シングルトンの多くの用途は、すべての静的メソッドとデータを持つクラスに置き換えることができます。パフォーマンスを犠牲にすることなくこれを実行できる場合は、実行してください。
3) オブジェクトの設定に顕著なコストがある場合は、Singleton を検討する必要があります。たとえば、初期化が必要な物理リソースである場合や、初期化が必要なルックアップ テーブルに依存している場合などです。その場合、Singleton を使用すると、オブジェクトを最初に使用するまで初期化コストを延期できますが、静的クラスは通常、アプリの起動時に初期化されます。オブジェクトがまったく使用されない場合、初期化コストを支払うことはありません。
シングルトンは、必要なインスタンスが 1 つだけで、設計を通じてそれを強制したい場合に使用する必要があります。グローバルな副作用が発生するため、使用しないでください。
あなたの場合、クラスのインスタンスを 1 つだけ制限したいので、それは理にかなっていると思います。
シングルトンには用途があります。彼らにも虐待があり、彼らを嫌う理由や、テストを困難にする理由はたくさんあります。
これがシングルトンパターンの小さな防御です。
時々、プログラムは本当に特異なものを表現したり、それと相互作用したりする必要があります。例は物理リソースです。たとえば、複数の「stdout」を持つことはできません。そして、OSプロセスの表現（例：J2MEのMidlet）。
クラス/インターフェースを使用してカプセル化を行う場合のようなシングルトンと、そうでなければ裸のグローバル変数になるような利点は、それだけの価値があります。
シングルトンは、Webプログラミングを使用している場合に意味があります。通常、リクエストごとに1つのページ出力クラスのインスタンスと1つのユーザーオブジェクトのみが必要です。ただし、データベースは異なります。特権の分離を実装することは、複数のdbオブジェクトが必要な理由です。
静的インターフェイスメンバーを許可しない言語（.NETなど）では、シングルトン（および同様のもの）が使用されます。シングルトンを提供することにより、インターフェースをインスタンスとして提供できるインスタンスが得られます。したがって、.NETでは、例は次のようになります。
Comparer<T>.Default-IComparer<T>ソートの実装を提供しますTEqualityComparer<T>.Default-IEqualityComparer<T>ハッシュ/同等性テストの実装を提供しますTこれは目的を達成するための手段です。それは私たちがやろうとしていることではなく、合理的な「方法」にすぎません。
「IDマップ」の例に関しては、個人的にはそれをインスタンスに保持し、すべてのコードでインスタンスを使用できるようにします。他のものとは別に、テスト間でマップを破棄できる場合、または（後で）複数のIDマップを同時に持つことができる場合は、テスト容易性に役立ちます。
アプリケーション内のさまざまなイベントを1つのファイルに記録したい場合を考えてみてください。その場合、シングルトンクラスのLogが役立ちます。アプリケーションの異なる部分がLogクラスの同じインスタンスにアクセスするためです。
私の個人的なガイドラインは、後でクラスの 1 つのオブジェクトをインスタンス化できる場合は、クラスをシングルトンとしてハードコーディングしないことです。これにより、シングルトンは非常にまれになり、多くの場合、アプリケーション コードでは不要になります。これは、Spring などの DI フレームワークを使用する場合に特に当てはまります。
シングルトンはフレームワークの「エントリ ポイント」として使用されますが、(依存関係階層の開始時に) 「ルート シングルトン」として使用し、残りのコードをそのシングルトンにできるだけ依存させるという規則があります。可能。