Construisons un pont entre certaines modifications qui ne seront pas implémentées pareilles et leur utilisation dans le code. C’est ici, qu’intervient le pattern : Bridge.
Il est par exemple très utile pour l’utilisation de différentes versions d’une dll, d’api.
Pour suivre le projet : le github.
Pour découvrir d’autres patterns :
Problématique ?
Prenons le cas de notre jeu vidéo.
Cas 1 – Les mises à jours du vaisseau
Chewbacca souhaite utiliser un vaisseau pour aller battre les stormtroopers.
Or, ce vaisseau a reçu plusieurs mises à jour.
Il peut utiliser par exemple des lasers génération 1, ou bien des lasers à double visées (plus puissant).
Comment faire pour qu’il puisse tester les différentes versions des armes du vaisseau ?
Cas 2 – Vaisseau et speeder bikes avec les mêmes armes.
Nous avons des vaisseaux spatiaux et des speeder bikes dans notre jeu.
Tous les deux sont équipés d’armes, à priori identiques : des lasers.
Une première idée serait de faire de l’héritage :
- VaisseauAvecLaser héritant de Vaisseau
- SpeederAvecLaser héritant de Speeder
Et nous voilà, à démultiplier les sous classes suivant les attributs.
Comment éviter cela ?
Une première solution
Dans les deux cas, la solution est d’extraire ce qui peut changer, indépendamment du reste.
Nous remarquons que la partie avec Arme, ou avec Laser est une partie qui peut changer.
On va donc mettre en place un Bridge, séparant ce qui va se différencier, du reste.
Prenons le cas 1, nous aurons :
- Une classe d’abstraction : Gun, qui va utiliser être le bridge proposant d’enapsuler le bon laser
- Une interface d’accès : IWhithLaser, proposant la méthode GenerateEnergy()
- Les classes de mises à jour : OldLaser, et Version2Laser
Comment faire ?
Voici le diagramme de classe :
Voici la mise en place :
D’autres patrons possibles
Vous pouvez utiliser un patron qui ressemble : Strategy, ou bien Adapter.
