Est-ce que le travail Mediator modèle dans cette situation?

Question

Donc, pour mon projet en cours, il y a essentiellement trois principales classes Java:

1. GUI
2. Messagerie instantanée
3. Calcul

Pour l'essentiel, il faut avoir une communication complète, nous avons donc décidé d'utiliser l'approche de médiateur plutôt que de permettre à l'interface graphique pour exécuter l'ensemble du projet.

En fait, le médiateur va encapsuler la communication. Le problème que nous avons rencontré est de savoir comment permettre aux composants de l'interface graphique pour mettre à jour sans avoir à construire une tonne de méthodes pour le médiateur pour appeler à tout moment quelque chose se termine.

Ex. Supposons que le GUI veut connecter l'utilisateur, il passe par le médiateur pour créer un fil et se connecter, mais le médiateur doit relayer le succès / échec de retour à l'interface graphique ainsi que de mettre à jour un message d'état.

L'autre question est des choses qui ont besoin de mettre à jour l'interface graphique, mais ne nécessitent pas le modérateur. Est-il pratique de simplement permettre à l'interface graphique pour créer une instance de cette classe et l'exécuter ou tout doit passer par le médiateur?

Notre conception originale avait juste l'interface graphique de gestion tout, mais il réutilisabilité vraiment tué. Y at-il une meilleure méthode de conception à utiliser dans ce cas?

Answer 1

Si vous trouvez observateur d'apporter trop de frais généraux, médiateur peut être la meilleure façon d'aller. Je pense vraiment que vous ne devriez pas avoir l'interface graphique Animez. Si vous allez utiliser le modèle de médiateur, le médiateur lui-même doit être responsable. Quelque chose que vous pourriez envisager est une variante du modèle de commande. Si vous utilisiez Ruby, je pourrais recommander callbacks fonction passant autour comme un moyen d'éviter d'avoir le médiateur contacter l'interface graphique pour chaque petite chose. Mais comme il est de Java, une certaine forme d'encapsulation d'une action dans le style de modèle de commande peut aider.

Answer 2

Si vous ne voulez pas le rappel / notification à triggerd par le médiateur, vous pouvez injecter le rappel dans la fonction de connexion et ont connexion appeler quand il se termine.

Je ne sais pas comment vous y prendriez injecter le rappel en Java, bien que. Dans une langue où les fonctions sont des citoyens de première classe, vous pouvez simplement passer la fonction, mais vous êtes en Java, donc je suppose que vous devrez utiliser le modèle de commande comme kmorris suggéré.

Answer 3

Vous pouvez également essayer d'avoir l'interface graphique donne au médiateur un objet de rappel qui gère la récupération des valeurs de retour ou les paramètres que vous valeurs doivent (une version du modèle de commande). Il y aurait alors un par appel de l'interface au médiateur.

Une autre idée est de regrouper les méthodes du médiateur appelle en morceaux sémantiquement liés. En particulier, si le médiateur a des sections où il a tendance à appeler plusieurs méthodes de l'interface graphique de suite:

   gui.a()
   gui.b()
   gui.c()

vous pouvez créer une seule méthode qui gère le résultat de l'appel tous les trois. L'avantage des méthodes groupées sémantiquement (à savoir setFileInformation sur setFileMenu, setTab, etc.) est également alors si vous avez besoin de changer l'interface utilisateur graphique, le contenu des méthodes peuvent changer, mais l'appel du médiateur ne rend pas peut.