どのようなタイプのデザインパターンがイベントを簡単にしますか？

Question

私はゲームに取り組んでいます。私は大量のリスナーを抱えています。

たとえば、ゲームの言語が変更されると、LanguageManagerはlanguageChangedイベントを送信し、関心のあるすべてのgui要素が新しいテキストを取得して再描画します。これは、関心のあるすべてのgui要素がLanguageListenerクラスを実装していることを意味します。

私が自分自身でたくさん行っていることは、依存関係を注入することです。 GuiFactoryは、FontManager（TTFフォントの配列を保持する）へのポインタを持つようにフォントを設定する必要があり、GuiSkinManagerも持っているので、ゲームのスキンに基づいてImage *を取得できます。これはこれを行う正しい方法ですか？

私の主な関心事は、リスナーとそれらの膨大な量です。特にguiのために。使用しているGUIライブラリーは、ほぼ完全にリスナー駆動型です。ほとんどの場合、ActionListenersで逃げることができますが、event.getSource（）== button2などの場合はまだifsをネストしています。

一般に、どのようなタイプのデザインパターンを使用して、大きなゲームプロジェクト私よりはるかに複雑ですか？

おかげで

Answer 1

リスナーは、多くの場合だけでなく、巨大な用途で使用されています。彼らを怖がらないでください。私は最大のJavaアプリケーションの1つを使って作業しており、そこにさまざまなリスナーの音色を見てきたので、それはそうであるように見えます。あなたは本当にイベントをリスニング嫌いならばMediatorは道の周りの可能性が少ないアプリケーションの場合

;）

Answer 2

代わりに、単一のコールバック（つまりを含むイベントタイプごとに一つのインタフェースを持つことのLanguageListener）、あなたは従うした場合。 Observerのデザインパターンでは、すべての種類のイベントに対してコールバックを持つ1つのインターフェイスxObserverがあります。

class GuiElementObserver 
{ 
public: 
    void LanguageChangedEvent(...) {} 
    void OtherEvent() {} 
}; 

デフォルトの空の実装では、具体的なクラスで興味のあるイベントのみを再定義できます。

依存関係については、コードをリファクタリングするたびに、単責任原則（http://en.wikipedia.org/wiki/Single_responsibility_principle）を使用したいと思います。あなたはGuiFactoryがフォントを設定する必要があると言いました...しかし、それは本当にフォントを設定する工場の責任ですか？

クラスの責任を本来の目的に限定した場合は、より希薄なクラス、より洗練されたコード、およびより少ない依存性が必要です。この場合、フォントマネージャを追加してフォント関連のコードを移動することが解決策になるかもしれません。