Non duplication de code - Design Patterns - Chaîne de responsabilité

Il arrive souvent que du code soit dupliqué.
Cette pratique est à bannir car à chaque évolution, le développeur est obligé de modifier l'ensemble des copies du code.
La bonne démarche consiste à mettre à disposition le code dupliqué à un seul endroit, et de l'appeler autant de fois que nécessaire.
Ceci arrive souvent avec l'implémentation de la chaîne de responsabilité
La chaîne de responsabilité (ou chain of responsability) est un design pattern.

Vous pouvez trouver une implémentation de ce dernier sur le site dofactory.com.

Ce dernier permet donc de consulter un ensemble d'objets pouvant répondre à une même requête, tout en construisant la chaine d'objets consultés dynamiquement.


 
Chaque objet consulté implémente donc la même interface que la classe Handler. Ces objets sont souvent sollicités de même façon

• Il teste la requête pour savoir si elle le concerne.
• Si oui, il exécute sont traitement.
• Si non, il transmette au suivant. 

Pour illustrer, lorsqu'on vous demande quelque chose soit vous savez et vous traitez, soit vous ne savez pas alors vous transmettez la demande à votre chef. Ce dernier fera de même avec la demande, ainsi de suite jusqu'à trouver la personne compétente pouvant la traiter.

Malheureusement ce schéma (souvent présent), est majoritairement dupliqué dans chaque classe dérivant d'Handler.

Afin d'éviter le copier-coller, sachant que chaque informaticien devrait être payé à la ligne de code qu'il n'écrit pas, j'utilise une classe intermédiaire évitant cette duplication.

En reprenant l'exemple de chez dofactory cela donne  pour la classe intermédiaire :

Et par conséquent les handlers concrets donnent, par exemple pour ConcreteHandler1 :

pour les autres, il suffit de changer le ConcernTest

Évidemment dans l'exemple ici,  l'Action est identique, mais dans une utilisation réelle cette méthode serait spécifique.

Nous avons donc réussi notre objectif, à savoir éviter de dupliquer la méthode HandleRequest.