Avant tout, je tiens à dire que je suis un partisan de l’inversion de dépendance et de l’injection de celle-ci. Il s’agit d’un design pattern qui doit être connu par tout développeur. D’ailleurs, l’inversion de dépendance fait partie des principes SOLID.
Il s’agit aussi du sujet que je vais aborder dans ce billet.
Avec le temps, j’ai développé une méfiance envers la pensée magique vis-à-vis le développement. Par définition, la programmation a quelque chose d’imparfait. Cette imperfection est principalement liée au fait qu’il s’agit d’une activité cognitive qui fait appel au bon jugement du programmeur.
Sans contredit, le but ultime de l’inversion de dépendance est de distancer une classe de ses dépendances en utilisant le plus un certain nombre d’abstractions.
Le but est louable. Cette pratique demande une rigueur et un souci constant de design et d’architecture. En théorie, il y a beaucoup de bénéfices à l’inversion de dépendances. Ultimement, cette pratique va mener à la mise en place de tests unitaires.
Oui à la testabilité. Cependant, qu’en est-il si la testabilité n’est pas l’objectif premier? Ultimement, est-ce que d’avoir quelques tests va ajouter beaucoup de valeur à ce qui est fait?
Là où le bât blesse, c’est que, dans bien des cas, c’est souvent mal implémenté.
J’ai déjà eu cette conversation avec des camarades développeurs. Il s’avère que de se prononcer contre ce design pattern est comme être pour la pauvreté ou en faveur des inégalités sociales. J’ai toujours l’impression de passer pour un criminel. Tu ne veux pas faire d’inversion de dépendances?! Tu ne sais certainement pas programmer.
Pour moi, il s’agit d’une question de contexte.
Ce que je dis c’est qu’au-delà des principes, il faut savoir quand et comment l’implémenter. J’ai vu un nombre incalculable de fois où une architecture reposant sur de l’injection de dépendance revenait à faire un mappage 1 pour 1 entre l’interface et le type concret. Sans compter que l’interface était un calque de la classe à implémenter.
Tant qu’à faire, pourquoi s’être donné le trouble de créer l’interface au départ? S’il faut, un jour, ajouter une autre implémentation, il va falloir tout réécrire, car le code est basé sur une prémisse incorrecte.
Mon point ici est que ce n’est pas automatiquement nécessaire. D’ailleurs, compter uniquement sur l’inversion de dépendance pour définir le design de son application est un peu faible. Il faut toujours garder en tête que SOLID est un acronyme pour cinq principes de design orienté objet.
Connaître SOLID permet de faire un acte conscient lorsqu’il est temps de mettre en place une architecture pour son application. Un peu comme des valeurs, il s’agit de principes à viser pour tenter de les atteindre en cours de route. Comme je mentionnais en introduction, la programmation est un acte imparfait, du chaos créé avec vos mains.
Êtes-vous d’accord avec ceci?
French Coding 