Mes 2 centimes ...
Oui et non.
Vous ne devriez jamais vraiment violer les principes que vous adoptez. mais vos principes doivent toujours être nuancés et adoptés au service d'un objectif plus élevé. Ainsi, avec une compréhension correctement conditionnée, certaines violations apparentes peuvent ne pas être de véritables violations de "l'esprit" ou du "corps de principes dans son ensemble".
Les principes SOLID en particulier, en plus de nécessiter beaucoup de nuances, sont finalement inféodés à l’objectif de «fournir un logiciel fonctionnel et maintenable». Ainsi, adhérer à un principe SOLID particulier est contre-productif et contradictoire lorsque cela entre en conflit avec les objectifs de SOLID. Et ici, je constate souvent que la prestation des atouts maintenabilité .
Alors, qu'en est-il du D dans SOLID ? Cela contribue à augmenter la maintenabilité en rendant votre module réutilisable relativement agnostique par rapport à son contexte. Et nous pouvons définir le "module réutilisable" comme "une collection de code que vous prévoyez d'utiliser dans un autre contexte distinct". Et cela s'applique à des fonctions, classes, ensembles de classes et programmes uniques.
Et oui, le fait de changer les implémentations de l'enregistreur place probablement votre module dans un "autre contexte distinct".
Alors, laissez-moi vous proposer mes deux grandes mises en garde :
Premièrement: tracer des lignes autour des blocs de code qui constituent "un module réutilisable" relève du jugement des professionnels. Et votre jugement est nécessairement limité à votre expérience.
Si vous n'envisagez pas actuellement d'utiliser un module dans un autre contexte, il est probablement acceptable qu'il en dépende impuissant. La mise en garde à la mise en garde: Vos plans sont probablement faux - mais c'est aussi OK. Plus vous écrivez, module après module, plus vous serez intuitif et précis: "J'aurai besoin de ça un jour de plus". Mais vous ne pourrez probablement jamais dire rétrospectivement: «J'ai tout modulé et tout découplé dans toute la mesure du possible, mais sans excès ».
Si vous vous sentez coupable de vos erreurs de jugement, allez à la confession et passez à autre chose ...
Deuxièmement: Inverser le contrôle n’équivaut pas à des dépendances d’injection .
Cela est particulièrement vrai lorsque vous commencez à injecter des dépendances ad nauseam . L'injection de dépendance est une tactique utile pour la stratégie globale d'IoC. Mais, je dirais que l' efficacité de l' ID est inférieure à celle d'autres tactiques - comme l'utilisation d'interfaces et d'adaptateurs - de points uniques d'exposition au contexte depuis le module.
Et concentrons-nous vraiment sur cela une seconde. Parce que, même si vous injectez une Logger
annonce , vous devez écrire du code sur l' Logger
interface. Vous ne pouviez pas commencer à utiliser un nouveau Logger
fournisseur différent qui prend des paramètres dans un ordre différent. Cette capacité provient du codage, au sein du module, d’une interface existante dans le module et comportant un seul sous-module (adaptateur) permettant de gérer la dépendance.
Et si vous codez sur un adaptateur, le fait qu’il Logger
soit injecté dans cet adaptateur ou découvert par celui-ci est en général assez insignifiant pour l’objectif de maintenabilité global. Et plus important encore, si vous avez un adaptateur de niveau module, il est probablement absurde de l'injecter dans n'importe quoi. C'est écrit pour le module.
tl; dr - Arrêtez de vous préoccuper des principes sans vous soucier de la raison pour laquelle vous les utilisez. Et, plus concrètement, construisez simplement un Adapter
module pour chaque module. Utilisez votre jugement lorsque vous décidez où vous tracez les limites du "module". Dans chaque module, allez-y et consultez directement le Adapter
. Et bien sûr, injectez le vrai enregistreur dans le Adapter
- mais pas dans tout ce qui pourrait en avoir besoin.