Voici une liste de modèles de conception utilisables dans les projets de jeux web (ou de sites): les design patterns. Chaque design pattern est décrit succinctement dans cet article.

Les Design Patterns

Les designs patterns sont des méthodes générales qui vous permettront de résoudre des problématiques usuelles.
Si le terme design patterns est littéralement traduit par patrons de conception, je vous propose de les voir comme des guides/méthodes aidant à coder.
Ils sont une synthèse des théories informatiques et de l’expérience des concepteurs logiciels, globalement étalées depuis les années 70 jusqu’aux années 2000
(cf Wikipedia).

Quand vous faites face à un problème de développement, demandez-vous “quel(s) patron(s) de conception puis-je appliquer?”.
Oui, au pluriel si besoin, car vous pouvez les coupler pour multiplier leur puissance.
Chaque patron est décrit ci-dessous, alors, inspirez-vous en. N’hésitez pas aussi à creuser les ressources du web, de vos collègues/professeurs et les livres papier pour trouver plus d’informations sur ces patterns.

Factory

Classe en charge d’instancier des objets d’une classe. Le patron peut aussi porter sur une méthode statique d’une classe (MyClass::instantiateForPost(...)), en charge d’instancier cette même classe (MyClass). On parle alors de static factory method.

Illustration du pattern Factory
Le pattern “Factory” correspond aux… Factories (usines, fabriques) du monde réel

Abstract Factory

La Factory peut elle-même instancier d’autres Factory. On parle alors d’Abstract Factory.

Illustration de l'abstract Factory
Une factory qui fabrique d’autres factories

Prototype

Créer de nouveaux objets (instances) par clonage d’un objet existant: le travail de création n’est fait qu’une seule fois, puis on se content de copier/coller l’instance pour créer les suivantes. Ce patron est parfois encapsulé dans une Factory.

Singleton

Le plus connu (mais ni le plus utile, ni le plus simple), il consiste à interdire l’instanciation d’une classe plus d’une seule fois. Il dérive parfois en “Multiton”, quand on limite le nombre d’instances à une valeur fixée (2, 3,…). Essayez de ne l’utiliser que pour représenter des éléments d’environnement (ie: le serveur et sa configuration) ou en guise de namespace de fonctions.

Le singleton consiste à n’avoir qu’une instance de la classe (deux exemples d’implémentations sont donnés)

Adapter

Passerelle entre deux classes, permettant d’utiliser une classe A comme s’il s’agissait d’une classe B.

Bridge

Séparer la sémantique et son implémentation. Somme toute, il désigne le principe des interfaces: l’interface dit “quoi” faire, la classe définit “comment” le faire.

Composite

Manipuler un objet ou un ensemble d’objets de la même façon: on souhaite pouvoir appliquer une commande (un appel de méthode) sans se soucier de savoir si on l’applique à un élément ou à un groupe d’élément.

Decorator

Attacher des responsabilités à une classe (héritage à la compilation, ou composition au runtime).

Facade

Grouper des objets pour les attaquer par une seule instance: au lieu d’appeler des dizaines d’objets pour effectuer un traitement complexe, on appelle un seul objet (la façade) qui se chargera de faire appelle aux objets qu’il encapsule.

Flyweight

Rassembler des données communes à de nombreux objets pour améliorer les performances, sous la forme d’une mémoire partagée.

Proxy

Créer un intermédiaire qui évitera les latences: au lieu d’appeler directement un service lent (BDD, requête HTTP, etc), on appelle un proxy qui se chargera d’appeler ce service lent.

Chain of responsibility

Créer une liste (chaine) d’objets, et appeler le premier d’entre eux. S’il sait répondre à l’appel, il y répond, sinon, il propage l’appel au suivant dans la chaine, et ainsi de suite. Le premier objet capable de répondre à l’appel stoppe cette propagation.

Command

Groupe des procédures (une méthode, ou des appels de méthodes) pour pouvoir les exécuter plus tard. A mon sens, c’est le pattern le plus simple à mettre en place.

Interpretor

Lire (et exécuter) un langage, en disposant d’une classe par symbole. Un pattern utilisé plutôt au niveau du langage qu’au niveau du code d’un jeu web (si vous devez implémenter un interpréteur de langage pour votre jeu web, vous avez surement raté votre architecture).

Iterator

Objet permettant de parcourir un ensemble d’autres objets.

Mediator

Element intermédiaire permettant de réduire le couplage entre deux autres éléments (ie: interface qui sera le médiateur découplant deux classes). On peut également réduire le couplage entre deux classes en créant une troisième classe qui sert de médiateur.

Memento

Stocker l’état d’un objet pour le restaurer par la suite (rollback). Ce sera certainement utile dans un jeu web, pour permettre au joueur d’annuler sa dernière commande par exemple (voir GoodUI, “Undos instead of confirms”).

Observer

S’enregistrer auprès d’une classe (l’observateur), qui pourra nous rappeler lorsque certains évènements surviendront sur une autre classe (l’observé), ce qui évite les “while(true){...}“.

Schéma du pattern observer
Schématisation du pattern Observer

State

Changer le comportement de l’objet sans changer l’instance de la classe. C’est à dire que la classe possède un état interne (attributs), qui définit son comportement externe.

Strategy

Sélectionner “à la volée” l’algorithme à exécuter, en fonction de différents critères. Par exemple, si un élément est dans le cache, l’algorithme get() délivre directement cet élément, et sinon, get() va demander cet élément au serveur, le récupérer, le mettre au cache puis le délivrer à l’utilisateur.

Template

Fixer des comportements standards, sans les implémenter. C’est assez proche des déclaration de méthodes dans les interfaces.

Visitor

Centraliser une méthode ou un comportement commun à plusieurs classes dans une classe dédiée.

Callback

Fonction passée en paramètre d’une autre. On peut le coupler au pattern command en passant la Command en callback.