Continuons notre aventure des Design Patterns, avec le Proxy. La dernière fois, nous avions un Design Pattern qui lui ressemblait quand même un peu : le Decorator. Patron très pratique pour encapsuler, protéger du code d’appel par exemple à un système d’authentification, il va permettre de proposer une interface commune (le Proxy) pour effectuer le travail commun.
Pour suivre le projet : le github.
Problématique ?
Restons avec nos amis de Star Wars, et Chewbacca. Nous l’aurez sans doute compris, notre but est de réaliser un jeu-vidéo autour du monde de la Guerre des Etoiles.
Comment mettre en place un système qui appelle :
- du code à protéger,
- des contrôles à faire avant utilisation, pour certaines méthodes
- ou bien, qui utilise des outils, des apis lentes
- des sites à distances
Plus concrètement, mettons le joueur à le niveau 1, il souhaite choisir une arme de niveau 1. Aucun problème n’es-ce pas ?
Que se passe-t-il s’il souhaite prendre l’arme de niveau 3, alors que les règles stipulent que ce n’est pas possible ?
Une première solution
Et bien, nous allons utiliser la même notion que l’on trouve dans un entreprise, avec une machine qui devient le Proxy d’internet :
- cette machine est le passage obligé de tous les pcs de l’entreprise pour aller sur Internet
- on peut faire des contrôles d’accès à chaque requête
Dans notre exemple, nous allons avoir :
- La classe normale qui fournit et crée une arme : Une classe WeaponProvider
- Le Proxy WeaponControlProvider qui va contrôler l’accès et l’authorization, et instancier le WeaponProvider, au besoin, et appeler le moteur de règles sur les armes
Les deux auront alors la même interface :
- IWeaponProvider
Comment faire ?
Voici le diagramme de classe :
Et la réalisation :
D’autres patrons possibles
Pour des proxys dynamiques, tout en ajoutant des fonctionnalités : le Decorator.