Quels types de design patterns rendent les événements plus faciles?

Question

Je travaille sur un jeu et je me retrouve avec un tas d'auditeurs.

Par exemple, lorsque la langue du jeu change, le LanguageManager envoie un événement languageChanged qui fait que tous les éléments gui intéressés obtiennent le nouveau texte et se redessinent. Cela signifie que chaque élément gui intéressé implémente la classe LanguageListener.

Une autre chose que je fais souvent est d'injecter des dépendances. Le GuiFactory doit définir des polices, il a donc un pointeur vers le FontManager (qui contient un tableau de polices TTF), il a également un GuiSkinManager pour obtenir Image* basé sur le thème du jeu. Est-ce la bonne façon de faire cela?

Ma principale préoccupation concerne cependant les auditeurs et leur grand nombre ; surtout pour l'interface graphique. La bibliothèque gui que j'utilise est presque entièrement basée sur les auditeurs. Je peux m'en sortir avec des ActionListeners la plupart du temps, mais j'ai toujours des ifs imbriqués pour if event.getSource() == button2 etc.

En général, quels types de motifs de conception sont utilisés pour éviter ces problèmes dans de grands projets de jeu beaucoup plus complexes que le mien?

Merci

Answer 1

Les auditeurs sont souvent utilisés dans de grandes applications également. Ne soyez pas effrayés par eux. Je travaille avec l'une des plus grandes applications Java et j'ai vu des tonnes de différents auditeurs là-bas, donc il semble que c'est la bonne façon de faire.

Pour les applications plus petites, Médiateur pourrait être une solution de contournement si vous détestez vraiment écouter les événements ;)

Answer 2

Au lieu d'avoir une interface par type d'événement contenant un seul rappel (ie. LanguageListener), si vous deviez suivre le modèle de conception Observer, vous auriez une interface xObserver avec un rappel pour chaque type d'événement.

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

Les implémentations vides par défaut vous permettent de redéfinir uniquement les événements qui vous intéressent dans les classes concrètes.

En ce qui concerne les dépendances, chaque fois que je refactore du code, j'aime utiliser le Principe de Responsabilité Unique (http://en.wikipedia.org/wiki/Single\_responsibility\_principle). Vous avez dit que la GuiFactory doit définir les polices... Mais est-ce vraiment la responsabilité d'une factory de définir les polices?

Si vous limitez les responsabilités de vos classes à ce pour quoi elles étaient initialement prévues, vous devriez avoir des classes plus légères, un code plus propre et moins de dépendances. Dans ce cas, peut-être ajouter un gestionnaire de polices et déplacer le code lié aux polices là-bas pourrait être une solution.