Design Pattern : Façade
Après quelques jours sans le net, je reviens avec des trucs sous le coude sur les design patterns. Je me suis dit que ça pourrait servir de faire des billets sur les design patterns qu'on utilise au boulot, et voici le premier de la série : le design pattern Façade.
Le principe est assez simple : on a un système (ensemble de classes ou ce que vous voulez) qui est relativement complexe à utiliser, et on cherche à en rendre l'accès plus simple. On fait donc une façade qui va présenter des fonctionnalités limitées, mais qui va être bien plus simple à utiliser.
On l'a utilisé au boulot de façon un poil détournée car en fait, comme vous le savez probablement, on fait du développement sur eBook en utilisant du Java et du C++ grâce à JNI. Côté C++, on a eu besoin de créer des objets à renvoyer (par exemple des Point, des Rectangle, ou alors des objets d'informations (contenant le titre du livre, l'auteur, etc...)). Au début on a fait ça de façon classique, donc au démarrage on choppait les classes correspondantes, puis les méthodes qui vont bien dans les classes en question (avec plein de setters, du coup), et au final, je trouve ça super moche.
En utilisant le design pattern Façade, on a fini par couper complètement la dépendance entre la partie C++ et la partie Java : une classe spécifique à notre implémentation C++ va servir de façade, et ne présente qu'une poignée de fonctions avec des méthodes 100% adaptées. On peut alors créer un objet d'informations avec exactement les informations disponibles côté C++, la méthode prend juste les arguments qui nous arrangent, et donc on n'a plus besoin d'avoir tous les setters à appeler un par un. De même, la création de tous les objets (Point, Rectangle...) est maintenant faite par la façade, ce qui évite d'avoir des dépendances inutiles entre le côté Java et le côté C++. Si jamais on s'amusait à changer les classes Point/Rectangle, ou qu'on voulait utiliser des polygones, par exemple, le code C++/JNI n'aurait rien à changer, on ajusterait juste la façade.
Au final, je dirai que c'est un design pattern un peu "tout con" car il ne nécessite pas vraiment de connaissance ni rien, et n'impose aucune contrainte sur le développement puisque ça ne fait que faciliter les interfaces entre classes, donc autant en profiter. Il permet aussi de factoriser du code si on a des opérations qui sont similaires ou identiques dans plusieurs classes (genre ouvrir un fichier, dumper le contenu, faire un traitement dessus, renvoyer un objet).