Le pattern Proxy - Découverte des design patterns

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.