De quoi exactement est fait le contrôleur GRASP?

Question

Quelle est l'idée derrière le modèle de contrôleur de Grasp? Mon interprétation actuelle est que parfois vous voulez réaliser quelque chose qui doit utiliser quelques classes mais aucune de ces classes n'a ou n'a accès aux informations nécessaires pour le faire, donc vous créez une nouvelle classe qui fait le travail , ayant des références à toutes les classes nécessaires (c'est, pourrait être l'expert en information).

Est-ce une vue correcte de ce qu'est le contrôleur de Grasp?

Généralement lorsque googling ou contrôleur SO'ing, je viens d'obtenir des résultats sur MVC (et autres joyeusetés) qui sont des sujets que je ne comprends pas, donc je voudrais des réponses qui ne supposent pas que je sais ASP.NET MVC ou quelque chose :(

Merci

Answer 1

Selon Wikipedia:

un objet contrôleur est un objet d'interface utilisateur non-responsable de la réception ou la manipulation d'un événement système

.

De Applying UML and Patterns:

Quel premier objet au-delà de la couche d'interface utilisateur reçoit d'abord et les coordonnées (« contrôle ») une opération de système?

Contrôleurs, dans tous les domaines - que ce soit dans MVC ou GRASP ou Patterns of EAA - sont sur la réception de l'entrée et la réponse aux événements.

Je le conceptualise très littéralement: pensez à un jeu vidéo contrôleur.

Il répond aux événements d'entrée - l'utilisateur appuyant sur les boutons. Il ne sait pas nécessairement quoi faire lorsque vous appuyez sur un bouton, mais il reçoit au moins l'événement.

En regardant le contrôleur, on peut facilement comprendre quels sont les événements du système - c'est-à-dire à quelles entrées il répond et comment l'utilisateur interagit avec le système.Sur un contrôleur de Nintendo, il est évident que les événements du système sont:

• Presse A
• Presse B
• Presse X
• Presse Y
• Presse ↑
• Presse ↓
• Press →
• Presse ←
• Presse L
• Presse R

Si nous devions prendre tous ces événements et construire un contrôleur logiciel pour traiter avec eux, ce serait un contrôleur MVC: ces événements sont tous concerné par le contrôleur physique tel que présenté à l'utilisateur - c'est "vue", si vous voulez. Mais il existe une deuxième couche d'événements d'entrée pour la plupart des jeux vidéo, où le mappage de boutons correspond à des opérations système spécifiques. Par exemple, si vous jouez en tant que Scorpion dans Mortal Kombat 2, en appuyant sur ← ← B déclenche l'un de vos coups spéciaux. Dans ce cas, le système pourrait avoir besoin de différents contrôleurs qui traitent de ces différents types d'événements:

Ici, le NES Button Controller est un contrôleur MVC qui garderait la trace de l'état des éléments de l'interface utilisateur - par exemple, se rappeler quels boutons ont été pressés dans quel ordre. En fonction de l'état de l'application (voir Application Controller - un autre!), Le NES Button Controller répondrait à certaines combinaisons de touches en invoquant des méthodes sur les autres contrôleurs - par exemple le Scorpion Controller - qui sont des contrôleurs de cas d'utilisation.

Ce qui est important est qu'en regardant la conception de ces objets de contrôleur, vous pouvez rapidement et facilement énumérer les événements du système auxquels ils répondent. En fin de compte, le contrôleur MVC est toujours une sorte de contrôleur GRASP - car ses méthodes ont tendance à représenter les événements du système, qui répondent à l'entrée de l'utilisateur. Mais il existe d'autres contrôleurs GRASP qui ne sont pas des contrôleurs MVC: Contrôleurs de cas d'utilisation. Un contrôleur de cas d'utilisation GRASP peut répondre à des événements système tels que "utilisateur crée une nouvelle vente" pendant qu'un contrôleur MVC répond à des événements tels que "système reçoit une demande PUT pour /sales/new" ou "un java.awt.event.ActionEvent incendies".

Answer 2

Les modèles contiennent des données. Les vues présentent les données. Les vues écoutent les modèles en utilisant le modèle Gang of Four Listener.

Les contrôleurs décident quoi faire avec l'entrée utilisateur. Soit ils appellent des méthodes sur les modèles, construisent de nouveaux objets dans l'ensemble actuel de modèles, suppriment des objets de l'ensemble actuel de modèles, recâblent des vues à différents modèles, ajoutent des vues, suppriment des vues ou reconfigurent des vues. GRASP est juste un outil pour mieux comprendre les logiciels, et, espérons-le, éviter de faire des erreurs flagrantes dans la création de nouveaux logiciels grâce à de bonnes pratiques de conception. Il n'a vraiment rien à voir avec MVC, mais il peut être utilisé pour mieux comprendre MVC.

La clé dans MVC est que le modèle n'est pas pollué avec du code qui gère les détails d'affichage. De cette façon, vous pouvez isoler la «logique métier» ou «ce que la classe est supposée faire» à l'intérieur du modèle uniquement. Les vues réagissent aux modifications du modèle car le modèle émet des messages à chaque vue qui s'est enregistrée par rapport au modèle (le modèle d'écouteur). Les messages sont souvent assez concis, ils n'ont fondamentalement pas besoin de contenir d'autres données que «le modèle a changé». Lorsque les vues sont averties qu'un changement s'est produit dans le modèle, la vue acquiert alors les données nécessaires à partir de l'interface publique du modèle. Une fois que la vue a les données dont elle a besoin, elle affiche les données à l'utilisateur (en utilisant l'interface que la vue devait prendre en charge). Cela isole la présentation des données à une classe qui se casse lorsque la vue change de manière incompatible et permet la modification du code de vue sans que la classe de modèle nécessite des modifications de "compatibilité".

Le contrôleur est responsable de savoir où se trouve le focus et quel modèle ou vue mettre à jour. C'est la colle qui met les choses ensemble, et est responsable du traitement correct des entrées.