quelle devrait être la position de l'enregistreur dans la liste des paramètres [fermé]

Dans mon code, j'injecte un enregistreur à plusieurs de mes classes via la liste des paramètres de leur constructeur

J'ai remarqué que je le mettais au hasard: parfois c'est le premier sur la liste, parfois le dernier, et parfois entre les deux

Avez-vous une préférence? Mon intuition dit que la cohérence est utile dans ce cas et ma préférence personnelle est de la mettre en premier afin qu'il soit plus facile de se faire remarquer lorsqu'elle est manquante et plus facile à ignorer lorsqu'elle est là.

Les bûcherons sont ce que nous appelons une «préoccupation transversale». Ils cèdent à des techniques telles que la programmation orientée aspect; si vous avez un moyen de décorer vos classes avec un attribut ou d'effectuer un tissage de code, alors c'est un bon moyen d'obtenir des capacités de journalisation tout en gardant vos objets et vos listes de paramètres «purs».

La seule raison pour laquelle vous souhaiterez peut-être transmettre un enregistreur est si vous souhaitez spécifier différentes implémentations de journalisation, mais la plupart des infrastructures de journalisation ont la flexibilité de vous permettre de les configurer, par exemple, pour différentes cibles de journalisation. (fichier journal, gestionnaire d'événements Windows, etc.)

Pour ces raisons, je préfère faire de la journalisation une partie naturelle du système, plutôt que de passer un enregistreur dans chaque classe à des fins de journalisation. Donc, ce que je fais généralement, c'est référencer l'espace de noms de journalisation approprié, et simplement utiliser l'enregistreur dans mes classes.

Si vous voulez toujours passer dans un enregistreur, ma préférence est que vous en fassiez le dernier paramètre de la liste des paramètres (faites-en un paramètre optionnel, si possible). Le faire être le premier paramètre n'a pas beaucoup de sens; le premier paramètre doit être le plus important, le plus pertinent pour le fonctionnement de la classe.

Dans les langages avec surcharge de fonction, je dirais que plus un argument est susceptible d'être optionnel, plus il doit être correct. Cela crée de la cohérence lorsque vous créez des surcharges là où elles manquent:

foo(mandatory);
foo(mandatory, optional);
foo(mandatory, optional, evenMoreOptional);

Dans les langages fonctionnels, l'inverse est plus utile - plus vous êtes susceptible de choisir une valeur par défaut, plus elle devrait être à gauche. Cela facilite la spécialisation de la fonction en lui appliquant simplement des arguments:

addThreeToList = map (+3)

Cependant, comme mentionné dans les autres réponses, vous ne souhaiterez probablement pas passer explicitement l'enregistreur dans la liste d'arguments de chaque classe du système.

Vous pouvez certainement passer beaucoup de temps à sur-concevoir ce problème.

Pour les langages avec des implémentations de journalisation canonique, instanciez simplement l'enregistreur canonique directement dans chaque classe.

Pour les langues sans implémentation canonique, essayez de trouver un cadre de façade de journalisation et respectez-le. slf4j est un bon choix en Java.

Personnellement, je préfère m'en tenir à une seule implémentation de journalisation concrète et envoyer tout à syslog. Tous les bons outils d'analyse des journaux sont capables de combiner les journaux sysout de plusieurs serveurs d'applications dans un rapport complet.

Lorsqu'une signature de fonction inclut un ou deux services de dépendances ainsi que des arguments "réels", je place les dépendances en dernier:

int calculateFooBarSum(int foo, int bar, IntegerSummationService svc)

Étant donné que mes systèmes ont tendance à ne comporter que cinq services ou moins, je m'assure toujours que les services sont inclus dans le même ordre sur toutes les signatures de fonction. L'ordre alphabétique est aussi bon que n'importe quel autre. (En plus: le maintien de cette approche méthodologique pour la manipulation des mutex réduira également vos chances de développer des blocages.)

Si vous vous retrouvez à injecter plus d'une douzaine de dépendances dans votre application, le système doit probablement être divisé en sous-systèmes distincts (oserais-je dire des microservices?).

Les enregistreurs sont un peu un cas particulier car ils doivent être disponibles littéralement partout.

Si vous avez décidé de passer un enregistreur dans le constructeur de chaque classe, vous devez définitivement définir une convention cohérente pour la façon dont vous faites cela (par exemple, toujours le premier paramètre, toujours transmis par référence, la liste d'initialisation du constructeur démarre toujours avec m_logger (theLogger), etc.). Tout ce qui sera utilisé dans l'ensemble de votre base de code bénéficiera un jour de la cohérence.

Alternativement, vous pouvez demander à chaque classe d'instancier son propre objet logger, sans avoir besoin de quoi que ce soit à transmettre. Le logger peut avoir besoin de connaître certaines choses "par magie" pour que cela fonctionne, mais coder en dur un chemin de fichier dans la définition de classe est potentiellement beaucoup plus facile à entretenir et moins fastidieux que de le passer correctement à des centaines de classes différentes, et sans doute beaucoup moins mal que d'utiliser une variable globale pour contourner cet ennui. (Certes, les enregistreurs sont parmi les très rares cas d'utilisation légitimes des variables globales)

Je suis d'accord avec ceux qui suggèrent que l'enregistreur doit être accessible de manière statique plutôt que transmis aux classes. Cependant, s'il y a une bonne raison pour laquelle vous voulez le transmettre (peut-être que différentes instances veulent se connecter à différents emplacements ou quelque chose), je vous suggère de ne pas le passer en utilisant le constructeur mais plutôt de faire un appel séparé pour le faire, par exemple Class* C = new C(); C->SetLogger(logger);plutôt queClass* C = new C(logger);

La raison de préférer cette méthode est que l'enregistreur n'est pas essentiellement une partie de la classe mais plutôt une fonctionnalité injectée utilisée dans un autre but. Le placer dans la liste des constructeurs en fait une exigence de la classe et implique qu'il fait partie de l'état logique réel de la classe. Il est raisonnable d'attendre, par exemple (avec la plupart des classes mais pas tous), que si X != Yalors , C(X) != C(Y)mais il est peu probable que vous tester l' inégalité de l' enregistreur si vous comparez aussi les instances de la même classe.

Il convient de mentionner, quelque chose que je n'ai pas vu les autres réponses aborder ici, qu'en faisant l'injection de l'enregistreur via une propriété ou statique, il est difficile (euh) de tester à l'unité la classe. Par exemple, si vous faites injecter votre enregistreur via une propriété, vous devrez maintenant injecter cet enregistreur à chaque fois que vous testez une méthode qui utilise l'enregistreur. Cela signifie que vous pouvez aussi bien le définir comme une dépendance de constructeur car la classe le requiert.

La statique se prête au même problème; si l'enregistreur ne fonctionne pas, alors toute votre classe échoue (si votre classe utilise l'enregistreur) - même si l'enregistreur ne fait pas nécessairement partie de la responsabilité de la classe - bien que ce ne soit pas aussi mauvais que l'injection de propriété parce que vous sachez au moins que l'enregistreur est toujours "là" dans un sens.

Juste un peu de matière à réflexion, surtout si vous utilisez TDD. À mon avis, un enregistreur ne devrait vraiment pas faire partie d'une partie testable d'une classe (lorsque vous testez la classe, vous ne devriez pas également tester votre journalisation).

Je suis trop paresseux pour transmettre un objet de journalisation à chaque instance de classe. Donc, dans mon code, ce genre de choses se trouve soit dans un champ statique soit dans une variable locale de thread dans un champ statique. Ce dernier est plutôt cool et vous permet d'utiliser un enregistreur différent pour chaque thread et vous permet d'ajouter des méthodes pour activer et désactiver la journalisation qui font quelque chose de significatif et attendu dans une application multi-thread.