Projet Bouboules

Date de publication : 12/05/2002

Exemple de modélisation d'un "univers" à l'aide du design pattern Observer et développement d'un affichage graphique de celui-ci.

1. Description
2. Le design pattern Observer
3. Téléchargement

1. Description

Ce projet a été réalisé à la suite d'une discussion sur le forum Delphi de Developpez.com.
Un des participants au forum était en train de réaliser un editeur de niveau pour un jeu. Cet éditeur devait permettre de positionner des "boules" de couleurs et de taille différentes librement sur une aire de jeu. Il était également nécessaire de visualiser le fait qu'une ou plusieurs boules soient en contact à l'aide d'un trait reliant celles-ci.

La démarche de l'auteur (je l'imagine car je n'ai pas vu les sources) a été une démarche très classique dans l'utilisation des outils RAD :

Recherche des composants existants correspondant à peu près à ce que l'on cherche à réaliser. Dans notre cas précis, un TGroupBox contenant des TShapes.
Utilisation des évènements disponibles pour coder les fonctionnalités de l'éditeur. Ici, utilisation du mécanisme de Drag and Drop de Delphi.
Tentative de modifer les propriétés et comportements de ces objets pour les adapter aux nouvelles fonctionnalités de l'éditeur. Dans notre cas, comment faire pour tracer des lignes entres les TShapes (de centre à centre).

Les véritables problèmes commencent généralement à arriver à partir de la troisième étape. En effet, c'est souvent à ce moment que l'on commence à utiliser les objets fournis par Delphi en les détournant de leur schéma de fonctionnement. Dans certains cas simples, il est possible d'y parvenir sans trop de difficulté. Mais il arrive souvent que le code nécessaire à cette opération devienne beaucoup plus important que le code de l'éditeur lui-même.
Dans ce cas, il vaut mieux s'arrêter et se poser une question simple mais très importante : ne serait-il pas plus judicieux de créer les objets nécessaires à l'application plutôt que de "bricoler" ceux offerts par Delphi ?
Cette question en masque une autre plus fondementale : quelles sont les fonctionnalités que l'application doit proposer ?
En principe, si on s'est posé ces questions, la réponse à la première devient évidente. Oui, il est plus "économique" et beaucoup plus gratifiant de développer les objets qui vont représenter l'"univers" de mon application (données, comportements, visualisation).
Mais comment faire ? Quel principe adopter ?

2. Le design pattern Observer

Dans le cas qui nous intéresse, il est assez facile de décrire le principe général.
Nous avons des objets décrivant l'univers, c'est à dire les propriétés et méthodes décrivant le niveau de jeu :

Une boule est un objet ayant certaines propriétés comme la taille, la position dans un repère, la couleur,etc.
Les méthodes vont permettre de répondre à quelques questions simples comme : 2 boules sont-elles en contact ?

Nous avons également un éditeur graphique. Celui-ci sera chargé de 2 missions :

Représenter graphiquement l'état de l'univers à un instant donné.
Permettre à l'utilisateur de modifier l'état de l'univers grâce à la souris et au clavier.

Notre découpage nous donne donc un document (univers réel) et un (ou plusieurs) éditeurs. Ce cas de figure peut facilement être représenté par le "pattern" Observer.
Il est hors de propos de tenter d'en faire une définition complète ici, mais voici le principe de base de celui-ci :

Les objets de l'"univers" réel sont appelés sujets.
Les objets manipulant les sujets sont appelés observateurs.
Lorsqu'un sujet est modifié, celui-ci doit en avertir ces observateurs.
Lorsqu'un observateur est averti de la modification d'un sujet, il réalise les opérations lui permettant de se mettre à jour par rapport à la modification ayant eu lieu.
Pour pouvoir être averti des modifications d'un sujet, un observateur doit pouvoir s'enregistrer auprès du sujet.

Ce simple mécanisme de base permet d'obtenir un effet très important : le sujet n'a pas besoin de connaître le type de l'observateur.
Il sait seulement que celui-ci possède un moyen d'être averti d'une modification. L'observateur peut donc être à peu près n'importe quoi : un éditeur graphique ou textuel, un système de sauvegarde des sujets, un système de statistiques, etc.
Le deuxième intérêt de cette méthode est qu'il peut y avoir autant d'observateurs que nécessaire. Il est donc possible d'avoir, par exemple, un éditeur graphique ET un éditeur textuel ET un système de statistiques en même temps à l'écran sans avoir de problème d'interaction. Je conseille vivement à ceux qui ne connaissent pas ce "pattern" de faire quelques recherches sur le web afin d'en apprendre un peu plus.

3. Téléchargement

Le projet Delphi 5 compressé dans une archive zip : Bouboules.zip