2

健全な管理のためにシングルトン クラスを使用することの長所と短所は何ですか?

私はそれが構造上非常に反 OOP であり、潜在的に間違った道を進むことに巻き込まれたくないことを懸念していますが、より良い代替手段は何ですか?

4

3 に答える 3

1

ややこしい話題ですが、サウンドマネージャスタイルのクラスは、初期化されるべきではないクラスの有力な候補であると言えます。

同様に、キーボード入力マネージャー スタイルのクラスが完全に静的なクラスであれば問題ないと思います。

私の推論のためのいくつかのメモ：

  • すべてのサウンドを処理する複数のインスタンスを期待することはありません。
  • 簡単にアクセスできます。サウンドは、特定のオブジェクトのみがアクセスできるものではなく、アプリケーション レベルのユーティリティのように見えるため、この場合は良いことです。たとえば、ゲームの Player クラスを静的にすることは、設計上の選択として非常に不適切です。これは、ゲーム内の他のクラスで Player を直接参照する必要があるものがほとんどないためです。
  • たとえば、ゲームのコンテキストで、サウンド マネージャーのインスタンスへの参照が必要なクラスの量を想像してみてください。敵、効果、アイテム、UI、環境。なんという悪夢でしょう - 静的なサウンド マネージャ クラスを持つことで、この要件がなくなります。
  • サウンドにアクセスすることがまったく意味をなさないと考えることができるケースはあまりありません。サウンドは、マウスの移動、爆発効果、ダイアログのロードなど、ほとんどすべての場合に適切にトリガーできます。静的クラスは、アプリケーション内の他のクラスの大部分との関連性または使用がほとんどない場合は不適切です。・音がします。

いずれかの方法; ここに表示される可能性のある反対の答えを相殺するのが私の見解です。

于 2012-05-10T03:32:47.050 に答える
0

グローバルが悪いのと同じ理由で、それらは悪いです。いくつかの有用な読み物:

http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx

より良い代替手段は、それをアプリケーション クラスのメンバーとして持ち、サウンドを処理する必要があるモジュールのみにその参照を渡すことです。

于 2012-05-10T01:51:33.873 に答える
0

「マネージャー」は通常、本質的に非常に複雑なクラスであるため、単一責任の原則に違反する可能性があります。ボブ・マーティンおじさんの言葉を借りれば、何かのクラスを「マネージャ」と呼びたくなる時はいつでも、それはコードのにおいです。

あなたの場合、少なくとも 3 つの異なる責任を負っています。

  1. サウンドの読み込みと保存。
  2. 必要に応じてサウンドを再生します。
  3. ボリュームやパンニングなどの出力パラメーターの制御。

これらのうち 2 つはシングルトンとして実装される可能性がありますが、このパターンには常に細心の注意を払う必要があります。これは、それ自体が SRP に違反し、間違った方法で使用するとコードが密結合になるためです (代わりに、おそらくSwiftSuspendersなどのフレームワークを使用して、依存性注入パターンを使用しますが、必ずしもそうではありません):

  • サウンドのロードと保存は、基本的に厳密にデータ関連のタスクであるため、SoundModelアプリケーションごとに 1 つのインスタンスのみが必要な で処理する必要があります。
  • 出力パラメーターの制御は、おそらく中央の場所で処理したいものであり、グローバルなボリューム設定などを変更できるようにするものです。これはシングルトンとして実装される可能性がありますが、マスターSoundControllerがグローバルを処理するツリーのような構造である可能性が高くなります。設定、およびいくつかの子SoundControllersは、UI サウンド効果、ゲーム サウンド、音楽など、より具体的なコンテキストを担当します。

サウンドの再生は、多くの場所で、さまざまな方法で発生するものです。ループ (後で停止できるようにするために参照を保持する必要があります) またはエフェクト サウンド (通常は短く再生される) がある場合があります。 1回のみ）、または音楽（各曲は通常1回再生されますが、最後に達したときに後続の曲を自動的に開始する必要があります）。これらのバリエーション (および思いついたもの) ごとに、共通のSoundPlayerインターフェイス ( 、LoopSoundPlayerImpl、など) を実装する別のクラスを作成する必要があります。インターフェイスは、、のように単純にする必要があります。 、緊密に結合されたライブラリでも問題はありません。SequentialSoundPlayerImplEFXSoundPlayerImplplay()pause()rewind()

それぞれSoundPlayerがマスターSoundControllerとそのコンテンツ固有のものの両方への参照を保持できSoundModelます。これらは、静的参照になる可能性があります。これらはすべて独自のサウンド プラグインの一部であるため、通常はパッケージとして展開されます。したがって、ここでは密結合が大きな損害を与えることはありません。プラグインの境界:Mainパーティション内のすべてをインスタンス化し、それらを必要とするすべてのクラスにインスタンスを渡します。SoundPlayerゲーム ロジック内でのみインターフェイスを表示するなど。

于 2012-05-10T05:45:37.573 に答える