シングルトン クラスは、jvm ごとに 1 つのインスタンスしか持たないことを理解しています。
しかし、設計の観点から、クラスをシングルトンにするタイミングを知るにはどうすればよいでしょうか? ユーティリティ クラスがおそらくシングルトンの良い例であることは理解していますが、他に何がありますか?
シングルトン クラスは、jvm ごとに 1 つのインスタンスしか持たないことを理解しています。
しかし、設計の観点から、クラスをシングルトンにするタイミングを知るにはどうすればよいでしょうか? ユーティリティ クラスがおそらくシングルトンの良い例であることは理解していますが、他に何がありますか?
シングルトン パターンは絶対に使用しないでください。これはコードのテストを難しくし、基本的に派手なグローバル変数です。jvm ごとにクラスのインスタンスを 1 つ持つ場合は、jvm ごとにクラスのインスタンスを 1 つだけ作成するようにコードを設計します。そのためにシングルトン パターンを導入する必要はありません。この例については、Spring と「シングルトン」の使用方法を確認してください。それはそれを行う良い方法です。
アプリケーション内に複数のインスタンスを持つ意味がないオブジェクトには、シングルトンの動作を強制する必要があります。たとえば、アプリケーションが 2 つのSecurityManagerを持つことはあまり意味がありません。
2 つ以上のインスタンスがあると、アプリケーション、特にシステムソフトウェアが壊れる場合があります。良い例は、ウイルス対策アプリケーションです。リアルタイム監視コンポーネントの 2 つのインスタンスがあり、それぞれが不正なプロセスとして互いにフラグを立てていると想像してください。
Enterprise Service Bus (ESB)はどうですか? すべてのモジュールがBusの新しいインスタンスを受け取った場合、何も接続しません。複数のアプリケーションキャッシュインスタンスを持つことはどうですか? パフォーマンスの低下につながる他のキャッシュインスタンスで既に利用可能なものを取得することで、リソースを浪費することになります。
ですから、あなたがその考えを理解してくれることを願っています。2 つ以上のインスタンスを持つことで望ましくないアプリケーションの動作につながる可能性のあるあらゆるものは、Singletonになる候補です。