Souplesse et modularité grâce aux Design Patterns

Le plus simple pour comprendre le principe du pattern Proxy est de prendre un exemple. Lorsque vous surfez sur Internet, votre navigateur charge la page web que vous êtes en train de lire. Cette page web fait surement référence à d'autres objets, par exemple des images. Le navigateur commence à afficher la page tout en téléchargeant les différentes images. Les images qui ne sont pas encore chargées sont représentées par un carré d'une certaine taille avec éventuellement un texte alternatif. Voici une utilisation possible d'un objet proxy: donner une représentation d'un objet distant ou trop volumineux pour être mis directement en mémoire.

Ceci est une utilisation possible du pattern Proxy, il en existe plusieurs :

• Gestion des objets distants (sur disque dur, base de données, Internet…) :
• Gestion des objets volumineux, avec création à la demande à partir de ressources distantes :
• Gestion des droits d'accès : restreindre l'accès de certains objets à des utilisateurs particuliers :
• Gestion de la mémoire avec mise en cache des objets les plus souvent accédés, libération de mémoire à la demande, comptage du nombre d'instances en mémoire, etc. Plus généralement, le pattern Proxy s'applique à tous types de smart pointers.

Voici le diagramme de classes correspondant au pattern Proxy :

Lorsqu'on essaye d'accéder à la méthode methode du Proxy, celui-ci vérifie si l'objet (réel !) est accessible (chargé, présent en mémoire, droits d'accès suffisants). Si c'est le cas, le Proxy appelle la méthode methode de l'objet réel. Sinon, le Proxy renvoie une représentation intermédiaire de l'objet (« en cours de chargement », « accès refusé », etc.).

Dans le cas d'un éditeur de scènes 3D, on peut imaginer que l'outil nous permette de sauvegarder des objets afin de les réutiliser plus tard dans une autre scène. Ces objets seront alors sauvegardés dans des fichiers. Afin d'éviter de devoir charger l'intégralité de ces fichiers au démarrage de l'application (trop lourd, trop long), on peut créer des objets Proxy faisant référence aux différents fichiers.

Ce n'est qu'une fois l'application lancée que les objets iront chercher à la demande (c'est-à-dire lors de l'affichage dans le menu) les informations relatives aux différents objets dans les fichiers correspondants (avec bien entendu la mise en cache de ces informations et libération dynamique de la mémoire).

De même, si certains de ces objets sont trop volumineux pour être redessinés à chaque fois, le Proxy peut servir à en donner une représentation intermédiaire, moins détaillée.

Pour la gestion de nos objets, on a eu recours à de nombreux composants différents (des Factory Methods pour la création d'objets, un gestionnaire de Prototypes, un gestionnaire pour la mise en cache de certains objets Proxy…). On a alors besoin de simplifier l'interface permettant d'accéder à ces objets. Pour cela, on utilise une Facade.

La Facade consiste à créer une interface unique pour accéder à un sous-système. Elle permet donc de créer donc le point d'entrée pour un package. La Facade est unidirectionnelle : de l'extérieur (les modules utilisant le package) vers l'intérieur (le package lui-même) :

Lorsqu'il y a des échanges réciproques entre les composants du système, on parle plutôt de Mediator :

La Facade étant unique, elle peut-être implémentée comme un Singleton, ou alors n'être composée que de méthodes statiques.