Symfony expliqué à ma maman, 3ème partie : le découplage
Alors que j’avais presque fini l’épisode sur le MVC, j’en suis venu à réaliser qu’il manquait une étape. Un concept capital dans toutes nos histoires de framework, de boîte à outils et de méthodologie. Je ne vous fait pas languir plus longtemps : il porte le nom de découplage.
Pour une fois, le champ lexical auquel le concept est emprunté n’est pas celui du BTP, même si on n’en est pas loin : c’est celui de l’électricité. Découpler y signifie supprimer le couplage entre deux circuits (ok, on est proche de la lapalissade, mais bon).
L’exemple le plus parlant sera celui de la prise électrique. Si on n’avait pas défini de standard ni un principe de prises mâles et femelles, on vivrait dans un monde où les appareils électriques ne pourraient être vendus prêts à être branchés, où il faudrait faire intervenir un électricien pour les raccorder au réseau, et où une fois installés on ne pourrait plus les déplacer ni les brancher ailleurs (sauf à répéter l’intervention). Assombrissons le tableau, et imaginons que dans ce même monde le réseau électrique n’aie pas de tension standard, mais distribue du 230 volts ici, 110 là, 3.14 ailleurs, etc. Non seulement il faudrait une manipulation technique pour connecter le grille-pain, mais aussi pour l’adapter à la tension. Manip’ à répéter à chaque déplacement de la bête…
Le problème que l’on aurait dans un tel monde serait celui d’un très fort couplage entre les appareils et le réseau électrique. Inutile de vous faire un dessin pour expliquer à quel point ça ne serait pas commode. Pour rester poli et ne pas dire chiant. Ah mince je l’ai dit.
En informatique, on s’est rapidement soucié du couplage, que ce soit du point de vue matériel comme pour les prises électriques en définissant des standards plus ou moins universels (PCI, RS232, USB, firewire…), ou logiciel (dans les programmes, ou dans les couches inférieures, par exemple le modèle adopté pour l’interconnexion des réseaux, OSI, mais c’est un autre sujet).
En ce qui concerne le sujet qui nous intéresse, le développement d’applications web via les frameworks en général et Symfony en particulier, le découplage est une notion critique.
Elle fonde l’organisation du framework lui-même, et sous-tend toutes les bonnes pratiques qui vont avec et doivent être appliquées dans le code spécifique à l’application.
Interfacer pour mieux découpler
Pour le formuler autrement, le découplage consiste en l’indépendance maximale de toutes les « briques » entre elles. Mais comme ces briques doivent communiquer, leurs interfaces, c’est-à-dire leur frontières de communication, doivent être codifiées.
C’est pourquoi en électricité on a réduit les nombres de connecteurs et définit des standards. C’est pourquoi en informatique on a défini des protocoles, autrement dit des règles d’échange. Car pour permettre le découplage, il faut se concentrer sur l’endroit — si je puis me permettre — où ça s’accouple, et l’abstraire des contingences et des spécificités (amen).
De la même manière qu’on ne souhaite pas avoir à changer de grille-pain si on change les prises ou si on déménage, on veut pouvoir faire abstraction, en développant une application web, de la façon dont l’accès aux données est géré (il nous suffit de savoir qu’il l’est), du type de serveur de base de données (on veut idéalement pouvoir utiliser n’importe lequel). Bref, on veut pouvoir se brancher dessus sans avoir à se demander comment. Aussi simplement qu’en branchant une prise mâle dans une prise femelle.
D’une manière générale, les fonctionnalités du framework doivent pouvoir être utilisées les unes indépendamment des autres, sans quoi leur mise en œuvre reviendra la plupart du temps à écraser une mouche avec un marteau-piqueur, ou pour rester sur notre champ lexical du jour, à faire construire une maison entière pour pouvoir brancher notre grille-pain.
Cette indépendance des « éléments » a un deuxième intérêt, non des moindres : il rend possible l’évolution ou la réparation des uns sans avoir à intervenir sur les autres.
Dans la vie bien découplée, vous pouvez acheter une cafetière neuve (ouaip, changeons d’objet électroménager, ça commence à devenir saoulant le grille-pain) sans avoir à refaire toute votre installation électrique, non ? Et bien si votre code et votre application sont eux aussi correctement découplés vous devez pouvoir modifier, mettons, votre logiciel d’envoi de mail sans avoir à retoucher à tous les endroits où vous envoyez des mails.
En résumé, si vous voulez briller en société (ou en lan party, encore que..) pensez à caser « découplage » au détour d’une saillie, ça fait toujours son effet. Si vous voulez briller en tests unitaires, c’est bien aussi, mais ça sera l’objet d’un épisode de la saison 2.
Dans le prochain épisode, cette fois c’est juré-craché-si-je-mens-je-vais-à-Denfert, on parlera de MVC…
Tags : découplage, design patterns, framework, principe, symfony
mercredi 23 septembre 2009 à 14 h 42 min
C’est surtout pour les tests unitaires, effectivement, que cette capacité à isoler et étanchéïfier les composants entre eux en s’affranchissant des interdépendances s’avère juste indispensable. C’est tout le problème d’ailleurs avec une partie de l’architecture de symfony 1.x, comme le montre très bien Bernhard Schussek dans son excellent billet au sujet des méfaits du singleton sfContext : http://webmozarts.com/2009/07/01/why-sfcontextgetinstance-is-bad/
D’ailleurs, j’ai cru comprendre que ta maman attendait maintenant avec une impatience fébrile que tu lui narre les aventures trépidantes de l’injection de dépendance, qui est finalement un épilogue plausible à tout ça ;)
mercredi 23 septembre 2009 à 15 h 28 min
Le cours sur le PVC, c’est quand ? j’ai acheté 80km de tuyaux pour me faire un vibraphone pas cher, mais j’attends toujours …
mercredi 23 septembre 2009 à 15 h 30 min
T’es viré.
mercredi 23 septembre 2009 à 21 h 43 min
Ha … il est loin le temps ou j’faisais des sfContext::getInstance()->getI18N()->__(« …. ») dans mes app.yml… (loin = juin dernier).