さまざまな理由でシングルトンの使用を避けるべきであることを何度も読み続けています。クラスが一意のシステム リソースを表す状況を正しく処理する方法を考えています。たとえば、SDL を使用した AudioOutput クラスです。SDL_OpenAudio は一度に 1 回しか開くことができないため、このタイプのオブジェクトを複数持つことは意味がありません。誤って複数のオブジェクトを作成するのを防ぐことは実際には良いことだと思います。
経験豊富なプログラマーがこれについてどう思うか疑問に思っているのですが、別のオプションがありませんか?
シングルトンの問題の 1 つは、ほとんどの場合、その使用が制御の反転の原則 (またはSOLIDに関する依存関係の反転) を破ることです。
Singleton は、複数のオブジェクトの作成を防止するだけでなく、コード内のどこからでもこのオブジェクトにアクセスできるようにします。オブジェクトの作成/アクセス方法を変更することにした場合、たとえば static 経由でアクセスする必要があると予想されるコード内のすべての場所を変更する必要があるため、これは悪いことですSingletonClass.GetInstance()。
また、単体テストを実装する場合、実際のオブジェクトの代わりにモックを使用することが必要になることがよくあります。あなたの状況では、モジュールを単体テストする必要があり、そのモジュールが を介して実際のオーディオ出力にアクセスした場合、SingletonClass.GetInstance()実際のオーディオ出力をスタブに置き換えることは非常に難しくなります。
一方、モジュールが依存性注入を介してオーディオ出力オブジェクトを取得した場合(たとえば、コンストラクターに渡されるパラメーターとして)、テスト中に、実際のオーディオ出力オブジェクトの代わりに、同じインターフェイスを実装したスタブを注入できます。
もちろん、そのようなオブジェクトを注入するレベルでは、シングルトンを使用して一度に 1 つのインスタンスしか存在しないようにすることができます。重要な点は、基礎となるコードは、オブジェクトの数や取得方法を気にするべきではないということです。それは、注入されたもので機能するだけです。
要するに、Singleton が本当に必要だと思われる場合は、Singleton を使用できますが、グローバル状態としてアクセスすることは許可しないでください。
デザイン パターンを賢く使用するのは難しい問題であり、多くの練習が必要です。
多くの人がシングルトンを使用しているのを見てきました. これは、たとえばマルチスレッド環境の場合や、設計上の欠陥を隠すことを意図しており、後でシステムを完全に再設計する必要がある場合など、しばしば災害をもたらします。
シングルトンを検討するときは、いくつかのことを考える必要があると思います。
ただし、あまり時間をかけないでください。常に最適な解決策であるとは限りませんが、場合によってはこれが許容できる解決策であり、マルチスレッド環境でない限り、おそらくめったに問題はありません。主にデザインの選択です。
デザイン パターンについてさらに知識を深めたい場合は、この本をお勧めします。これは、このトピックに関するほとんどのリファレンスです。
次の条件を満たしている限り、シングルトンで問題ありません。