Comment éviter le couplage serré?

Question

J'ai essayé de résoudre ce problème la semaine dernière et je n'arrive pas à trouver une solution qui ne nécessite pas de couplage singleton ou étroit. Je développe un jeu spatial 3D, dont une démo précoce est ici ...
www.sugarspook.com/darkmatters/demo.html
... et j'arrive au point d'ajouter des missions que le Le joueur pourra choisir parmi l'affichage tête haute (classe Hud).

La structure du jeu est:
La classe Game contient la classe Hud et la classe ObjectsList.
La classe ObjectsList contient divers objets de jeu, y compris le joueur, les différents types de vaisseau, les planètes et les orbitales (stations spatiales).
Les missions sont instanciées lorsque le joueur arrive à une certaine distance d'une orbitale.
Les missions sont ajoutées à une classe MissionsList, elle-même dans la liste ObjectsList.
Les missions peuvent devenir indisponibles et expirer sans avertissement (comme si elles étaient sélectionnées par un autre pilote). La liste affichée sur le Hud est donc dynamique et mise à jour régulièrement.
Auparavant, j'ai envoyé les missions envoyer des événements jusqu'à Game qui à son tour informe Hud du changement. Cela me semble un peu maladroit, car il y a différents «niveaux» plus profonds au Hud que l'information doit être transmise. Je finis avec beaucoup de mêmes fonctions tout au long de la chaîne.

La solution à laquelle je pensais consistait à injecter une référence à la classe MissionsList dans le Hud, lui permettant d'écouter les mises à jour de Missonslist. J'ai entendu dire que c'est une mauvaise habitude de mélanger l'état de quelque chose avec son affichage, mais je ne vois pas comment obtenir la liste des missions en direct. En revanche, si le Hud ne contient que des détails d'affichage sans référence à l'objet Mission qui a généré ces détails, quand un joueur sélectionne une Mission du Hud, comment puis-je déterminer quelle Mission a été choisie? Un couplage serré est-il correct dans ce cas? Ou devrais-je utiliser un singleton pour communiquer avec le Hud? S'il y a quelque chose de fondamentalement faux dans tout ce que je suggère, je me réjouis d'apprendre ce que c'est et quelle est la meilleure solution. Merci.

Answer 1

Eh bien la réponse simple est pourquoi ne pas coupler via une interface intermédiaire?

interface IMissionList 
{ 
    ObservableCollection<IMission> Missions{get;} 
} 

Puis dans votre bind injection de dépendance qui à quelque chose qui peut résoudre à une instance, singleton ou constante ou etc ...

puis l'injecter dans votre constructeur de Hud

Hud(IMissionList missionList){} 

maintenant vous êtes vaguement couplé à un contrat, la mise en œuvre de - qui peut être modifié à tout moment, tant que la mise en œuvre adhère au contrat. En outre, en raison de l'injection de votre Hud doit seulement se préoccuper de l'utilisation de IMissionList plutôt que de le trouver.

[Éditer] Désolé, ceci est en C#, mais j'espère que l'idée est utile. See for actionscript interfaces et Dependency Injection for Actionscript