Il existe de nombreux projets de type Simple Injector pour différents langages de programmation qui permettent, par le nom d'une classe, d'une interface ou d'un espace de noms, et parfois d'un dossier, d'enregistrer une classe ou un groupe entier de classes unies par cette fonctionnalité dans certains cas. C'est dans le but d'instancier automatiquement un objet sans spécifier explicitement ses dépendances. Cet enregistrement d'un groupe d'objets par une caractéristique commune dans le registre dans le but d'une instanciation ultérieure, j'appelle l'enregistrement automatique des dépendances.
Si vous instanciez explicitement une classe lors de son inscription dans le registre des dépendances, ce n'est pas le sujet de cet article.
Et quel est le problème avec ça?
Dans cet article, je partagerai ma frustration avec les projets qui utilisent l'enregistrement automatique des dépendances. Allons dans l'ordre.
Runtime vs temps de compilation
À l'aide de l'outil d'enregistrement automatique des dépendances, nous transférons la vérification de l'exhaustivité des dépendances enregistrées au runtime. Autrement dit, si au moment du lancement du programme, nous n'avons pas l'implémentation de l'interface nécessaire à l'exécution du code, nous en apprendrons au mieux au démarrage de l'application, et au pire - déjà pendant le fonctionnement du système et auprès des utilisateurs.
Voici un exemple. Si, dans le projet, certaines classes ont été enregistrées, par exemple, par leur espace de noms, et que vous en avez déplacé à un moment donné la classe, alors vous en apprendrez davantage sur le problème lors de l'exécution. La même chose se produira avec l'enregistrement automatique via l'interface, à la seule différence que le déplacement ne sera pas un problème, mais la suppression de l'interface entraînera un problème, dont vous apprendrez après le démarrage de l'application.
Le refactoring est beaucoup plus compliqué
Non seulement la refactorisation, mais aussi l'apprentissage du code devient très difficile. En effet, lors de l'utilisation de l'enregistrement automatique des dépendances, l'accès aux capacités modernes des environnements de développement est perdu, ce qui nous permettrait de savoir qui utilise cette classe en un clic (trouver la référence) et de répondre aux questions suivantes:
- Puis-je supprimer cette classe?
- Puis-je déplacer cette classe vers un autre espace de noms / dossier?
etc.
Outre le fait que nous sommes privés de la possibilité de vérifier l'exhaustivité des dépendances requises lors de la compilation, tout refactoring est l'espoir que nous disposions d'un mécanisme d'exécution sous forme de tests, de vérifications d'arbres de dépendances, etc. Et l'espoir est que cela fonctionne. Il est à noter que ces mécanismes non seulement ne garantissent pas à 100% que la composition du code est correcte, mais aussi beaucoup plus lent que la compilation.
Cacher la vraie complexité du système
Lors de l'instanciation manuelle des classes et de toutes leurs dépendances, vous pouvez être plutôt intimidé par la monstruosité du fichier dans lequel toute cette action aura lieu. En regardant des milliers de lignes de code pour instancier des classes et en les comparant à une douzaine lors de l'utilisation de l'enregistrement automatique des dépendances, je veux vraiment succomber à la tentation et aller du «côté obscur».
Mais que nous disent ces milliers de lignes de code d'instanciation d'objets? Le fait que ce module soit complexe, volumineux et qu'il faut penser soit à le structurer par l'allocation de sous-modules (qui eux-mêmes instancient explicitement leurs dépendances), soit à diviser ce module en plusieurs.
Cela peut sembler abstrait, mais en supprimant des moments aussi gênants que l'instanciation de centaines d'objets de nos yeux, la taille du projet augmente de manière incontrôlable et, par conséquent, nous manquons le moment où il devrait être divisé en plusieurs projets.
Dépendances supplémentaires
En enregistrant les dépendances et en ne contrôlant pas leur utilisation, nous arrivons tôt ou tard à une situation où, lorsque l'application démarre, beaucoup plus de classes sont enregistrées que ce qui est réellement nécessaire. Le simple fait d'ajouter à un dossier ou d'implémenter une interface peut entraîner l'enregistrement de cette classe dans le cas général.
Résumé
Est-il possible de vivre avec tous ces inconvénients et de ne pas les remarquer? Sûr! Mais je pense que cela développe de mauvaises habitudes de développement. Le fait est que la compilation et la saisie du code sont des outils pour vérifier l'exactitude du système. En les rejetant, nous arrivons à la conclusion que le système devient fragile, de sorte que les développeurs ont peur d'y changer quoi que ce soit. Et la peur des développeurs de changer le code conduit déjà au fait que la qualité de la base de code se dégrade, après quoi il devient un processus coûteux d'apporter des modifications à un tel code.
À quoi sert l'enregistrement automatique des dépendances?
Et vraiment, qu'est-ce qui est bon? Je suggère de discuter dans les commentaires des raisons pour lesquelles cette méthode a gagné en popularité. Il a sûrement des fans parmi ses lecteurs.