Programmation

Design pattern : le modèle MVC

Lors de ma participation à la Blueberry Jam 2017, je me suis rendu compte d’une chose : un code mal organisé, ça peut bousiller une jam. Cela rend difficile de corriger des bugs sans modifier toute l’architecture du jeu et créer ainsi des problèmes ailleurs, ça complique l’implémentation de nouveaux objets et ça provoque des répétitions de codes inutiles et coûteux… enfin bref, la modélisation est une étape primordiale et ceux qui la zappent s’en mordent les doigts ! Il faut savoir structurer son code AVANT de l’écrire, et pour cela, on a la chance d’avoir des outils efficaces : les design patterns.

architecture logicielle

Qu’est-ce que l’architecture d’un logiciel ?

Quand on débute en programmation, on a tendance à taper son code au fil de sa pensée. Un peu comme quand on écrit une dissertation de philo pour la première fois, on s’imagine que la petite ébauche qu’on a en tête vaut un plan détaillé au brouillon. De plus, on ne réfléchit pas forcément à la manière dont seront agencées nos classes les unes par rapport aux autres, certains même n’en prévoient pas et mettent toutes leurs fonctions dans le main(). Ensuite on pense à de nouvelles fonctionnalités, puis on se rend compte qu’on ne pourra pas les implémenter sans modifier du code en amont, qui évidemment impactera sur toutes les autres méthodes qui l’utilisent…. et c’est là qu’on se met en pls sous notre bureau, pleurant face à notre bouillie indigeste de code !

Toi, quand t’as planté tout ton code après une tentative d’optimisation.

L’architecture logicielle, c’est un peu l’outil divin qui va nous sortir de ce scénario infernal. Plus précisément, il s’agit d’une manière de décrire les différents composants, d’un ou de plusieurs programmes informatiques, ainsi que leurs relations et leurs interactions, souvent à l’aide de schémas. C’est donc un plan d’organisation de notre logiciel qui, s’il est conçu intelligemment, doit nous permettre de simplifier la maintenance (maintenabilité), et l’ajout de fonctionnalités (extensibilité). Pour les programmeurs plus expérimentés d’autres contraintes d’optimisation sont importantes à suivre comme la portabilité sur d’autres plateformes ou la compatibilité, la simplicité et plein d’autres encore. L’architecture d’un programme doit être solide, à l’instar de celle d’une maison qui, si elle n’est pas adaptée aux besoins du bâtiment, la verra s’écrouler :

Si votre architecture est fragile alors votre application est fragile. Si votre architecture est vulnérable alors il est inutile de croire que votre application est sécurisée car ce n’est pas le cas. – Maxime M.N. Zekeng, OpenClassrooms

Les design patterns, des outils de modélisation orientés objet.

Dans la langue de Molière,  on parle plutôt de patrons de conception. Il s’agit de modèles de solutions à des problèmes récurrents dans la conception d’un programme. Chaque patron possède un nom pour l’identifier, une problématique décrivant le problème qu’il résout, une description de la solution apportée souvent sous forme d’un schéma UML, et ses conséquences, c’est-à-dire la balance de ses avantages et inconvénients. En effet, en pratique rien ne vous empêche d’utiliser plusieurs patrons de conception pour combler des lacunes si cela est judicieux.

Outils de modélisation pur, ils sont indépendants de tous langages de programmation et peuvent donc être adaptés à différents langages ou moteurs de jeu. Il en existe énormément et sont classés par catégories. Il en existe trois de base : fonctionnel, créationnel et structurel. On va s’intéresser ici à un patron de structure puisqu’il permet l’organisation des classes d’un logiciel. Il est intéressant d’utiliser un design pattern déjà existant car plusieurs personnes dont des experts ont déjà testé et approuvé la solution, cela vous épargne du temps de réflexion. Ils sont connus et employés par grand nombre de développeurs donc cela facilite la compréhension au sein d’une équipe et permet de mettre en avant les bonnes pratiques de conception. Mais rien ne vous empêche de créer le vôtre ou d’en adapter un à vos besoins plus spécifiquement, ça reste des modèles flexibles et non des règles à absolument suivre.

Le patron Modèle-Vue-Contrôleur.

Le patron le plus couramment utilisé dans les jeux vidéo, mais également dans bien d’autres logiciels est le modèle MVC (Modèle Vue Contrôleur). Il propose d’utiliser trois classes ou modules regroupant des fonctions selon leurs utilités :

  • Modèle, c’est là que s’effectuent le traitement des données, le chargement, la traitance, le cryptage etc… D’ailleurs il est le seul module à interagir directement avec les données. Ensuite le modèle enverra ces informations à la vue.
  • Vue, elle contient tout ce qui sert à l’affichage sur l’écran. C’est par le biais de cette interface graphique que le joueur recevra les informations et pourra interagir avec. Elle n’interroge pas directement les fichiers ou la base de données, elle se contente de les recevoir du modèle et de les rendre à l’écran. Dans certaines variantes du MVC, notamment le MVVM (Modèle-Vue-Vue Modèle) et le MVP (Modèle-Vue-Présentation), elle peut également recevoir des instructions de l’utilisateur, comme un clic souris pour déplacer un joueur par exemple.
  • Le contrôleur est un peu le médiateur entre tout les modules. Il coordonne les transactions d’informations entre la vue et le modèle. Il récupère les entrées de l’utilisateur et informe les deux autres composantes du patron pour qu’elles réagissent en conséquence. Il est aussi à l’endroit où s’établissent les règles de contrôle, que ce soit pour le comportement des intelligences artificielles, la gestion des évènements ou toutes autres fonctions qui ne servent ni au rendu graphique, ni ne concernent les données. Pour ne pas s’y perdre on peut organiser ses fonctions par métiers ou comme disent les anglophones, en « business logic« .
Exemple de MVC par sce2.umkc.edu

Pourquoi faire un tel découpage ? On se rend compte aisément que dans ce modèle chaque pôle est indépendant. Même s’ils communiquent entre eux et se servent les uns des autres, on peut implémenter plusieurs vues et contrôleurs avec un même modèle. Cela résulte de la « séparation des concepts« ,  un principe de conception visant à rendre une architecture plus modulaire, où chaque fonction est incluse dans une couche correspondant à ce à quoi elle sert. En effet,

le contrôleur n’a pas à savoir comment sont stockées ou chargées les textures. C’est le modèle qui le gère et c’est un détail d’implémentation.
Le contrôleur n’a pas à savoir comment est fait l’affichage (OpenGL vs DirectX) C’est la vue qui le gère et c’est un détail d’implémentation.
[…]
Chacun expose une interface ou des objets que les deux autres peuvent utiliser. – foetus, forumeur sur Devellopez.com

Cela confère une maintenabilité et une extensibilité du code sympathiques !

Exemple d’un flux de traitement, lorsqu’un client envoie une requête à l’application :

  • la requête envoyée depuis la vue est analysée par le contrôleur (par exemple un clic de souris pour lancer un traitement de données) ;
  • le contrôleur demande au modèle approprié d’effectuer les traitements et notifie à la vue que la requête est traitée (via par exemple un handler ou callback) ;
  • la vue notifiée fait une requête au modèle pour se mettre à jour (par exemple affiche le résultat du traitement via le modèle). – Wikipédia

En résumé, le modèle MVC permet une modélisation claire et concise qui aide au partage des tâches des développeurs et aide à avoir une compréhension globale de l’architecture du jeu sans connaître les détails des parties sur lesquelles ils n’y travaillent pas. Cela permet également d’ajouter de nouvelles fonctionnalités. On peut aisément laisser tomber ses fichiers CSV car on préfère le JSON pour représenter des tilemaps par exemple, ainsi les données traitées par le modèle changent, certes, mais la façon de les rendre à l’écran demeure la même. De même, plusieurs Controllers gérant des entrées différentes (clavier, manette, souris etc..) peuvent être ajoutés sans souci.

Le week-end prochain je vous promet un exemple pratique : je vais tenter de restructurer le code des menus de mon jeu de jam Suicid Smart selon le modèle MVC ! N’hésitez pas à critiquer mon article en commentaires et à me corriger si nécessaire, car l’architecture est un domaine où je débute tout juste !


Merci au forumeur de Devellopez.com pour la correction de cet article ! (lien de la discussion, si ça vous intéresse !)

Sources :

Documentation sur le travail d’un architecte logiciel

Cours sur le MVC d’OpenClassrooms

Site dédié aux design patterns pour aller plus loin

Un exemple d’implémentation de MVC en java sur Developpez.com

Cours sur les design patterns

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s