Quand je fais TDD, cela me force à utiliser le principe Dependency Injection et je me retrouve avec un code faiblement couplé.Existe-t-il d'autres avantages pour le code à couplage lâche en plus de TDD?
On m'a dit qu'il est plus difficile de comprendre l'application qui a un code faiblement couplé.
Pouvez-vous me dire quels sont les avantages et les inconvénients du code faiblement couplé?
L'injection de dépendance n'entraîne pas automatiquement un faible couplage. Je suis d'accord avec les réponses ci-dessus sur les avantages du couplage faible. Le principal avantage de Dependency Injection est qu'il améliore la testabilité et qu'il vous aide à suivre le principe GoF du programme pour les interfaces, pas les implémentations. Mais vous pouvez aussi avoir un couplage élevé aux dépendances injectées.
L'autre avantage est de pouvoir remplacer des composants plus facilement lorsque vous avez plus d'une implémentation. Imaginez que vous ayez un système de panier, il stocke et lit normalement à partir d'une base de données, c'est la valeur par défaut. Mais vous pouvez injecter pour qu'il utilise un backend, ce qui n'est pas aussi bon mais cela fonctionne quand vous n'avez pas de base de données.
Comme il est faiblement couplé, il est très variable. Exactement. Si vous n'en avez pas besoin, le couplage lâche peut introduire de nombreuses indirections qui conduisent à un système avec plus de «profondeur»: vous devez regarder un niveau pour voir tout ce qui se passe.
Le plus grand avantage est que l'introduction de modifications à un module ne brise pas les autres modules de manière imprévisible.
Comme vous l'avez dit, les inconvénients du code faiblement couplé sont une complexité accrue, et il est difficile à comprendre. Il n'est généralement pas immédiatement apparent ce que le code fait quand il est faiblement couplé.
Comme d'autres l'ont dit: L'avantage est qu'il est beaucoup plus facile d'échanger d'autres éléments de code/modules/objets/composants lorsque les pièces ne sont pas dépendantes les unes des autres.
Comme pour tout design OO, il y a des compromis à faire - est-il plus important pour vous d'avoir un code hautement modulaire qui est facile à échanger? Ou est-il plus important d'avoir un code facilement compréhensible qui soit plus simple? Vous devrez décider cela.
Réutilisation, extensibilité et réduction des effets secondaires.