Pattern G.R.A.S.P Controleur
Nous avions déjà rencontré ce pattern dans le TD1 mais de manière implicite. Nous allons l’approfondir ici.
Problème initial
Comment coordonner les actions réalisées sur une Interface Graphique avec les bonnes actions systèmes correspondantes ?Solution associée
Créer un objet supplémentaire qui va faire la traduction d’une action physique en action système.Définition
Le pattern Contrôleur est un modèle très utilisé dans les systèmes actuels. Ce modèle est le premier qui n'est pas applicable aussi intuitivement que l’Expert, le Créateur et le Faible Couplage. Le pattern Contrôleur consiste en l'affectation de la responsabilité de la réception et/ou du traitement d'un message système à une classe. Une classe Contrôleur doit être crée si elle répond à l'un des cas suivants :- La classe représente un contrôleur de façade, c'est à dire l'interface d'accès à l'ensemble d'un système. C’est le cas si notre application possède une interface graphique
- La classe représente le scénario issu d'un cas d'utilisation. A ce moment-là on l’avait aussi représenté dans le diagramme de séquences.
Le contrôleur peut déléguer des tâches à d'autres objets, il existe surtout dans le but de coordonner les actions sur l’interface graphique et les événements système correspondants.
Exemple
Soit le scénario suivant :Un client effectue un achat sur une application. S’il clique sur le bouton « se connecter » l’application lui affiche le message « Veuillez entrer vos identifiants » par contre s’il clique sur le bouton « se déconnecter » l’application va regarder s’il est connecté et lui affiche le message « Au revoir » s’il été connecté ou bien le message « Vous n’êtes pas connecté » s’il n’était pas connecté.
Voyons tout d’abord ce que cela donne sans l’objet contrôleur sur un diagramme de séquence :
Et maintenant celle avec l’objet contrôleur :
La différence est flagrante : même si les deux solutions sont correctes, dans la 1ère solution c’est l’interface graphique qui se charge de tout faire c’est-à-dire récupérer les actions utilisateurs mais aussi et surtout de déclencher l’action système correspondante tandis que la 2ème solution sépare bien les actions.
Ainsi on voit bien que le fait d’ajouter l’objet contrôleur permet de bien séparer les différents rôles des objets et de limiter les informations que chaque objet doit connaitre et on en revient alors au pattern Expert…
A retenir
Le pattern contrôleur, fait partie du pattern architectural MVC (Model View Controler) qui permet d'organiser en couches (layer) une application, en respectant le modèle du domaine avec d'un côté, l'interface graphique utilisateur (GUI) et de l’autre la logique applicative avec le contrôleur et le noyau fonctionnel. Cela permet, de réutiliser les composants, et de pouvoir changer aisément l’interface graphique.Remarque : La solution du contrôleur n’est pas forcément à appliquer dans tous les cas. En effet s’il permet de respecter le pattern Expert et le modèle MVC il ne respectera pas toujours le pattern faible couplage car étant théoriquement relié à toutes les classes systèmes principales (celles qui ne peuvent pas être utilisées par d’autres classes) si l’on change l’une de ces classes on est obligé de modifier le contrôleur à chaque fois. Encore une fois tout dépend du contexte et des choix d’implémentation.