Als generelle Regel verwende ich die konstruktorbasierte Abhängigkeitsinjektion, aber in letzter Zeit arbeitete ich an einer Klasse, die von 4 anderen Klassen abhängig war. Da lange Argumentlisten schwer zu lesen sind, ersetzte ich den Konstruktor mit 4 Argumenten durch 4 Setter.
Als ich dies einem Kollegen erwähnte, argumentierte er, dass dies ein Code-Geruch ist. Er schlug vor, dass ich diese Klasse "auflösen" sollte.
Die Klasse selbst ist schon relativ klein; Es passiert einfach, dass mehrere Mitarbeiter den Großteil der Arbeit erledigen. Es besteht aus einer kurzen (~ 12 Zeilen, einschließlich Whitespace) Methode, die Aufrufe an 4 Mitarbeiter macht. Stimmen Sie der Behauptung zu oder nicht zu, dass dies ein Code-Geruch ist? Gibt es eine objektive Maßnahme, mit der ich ermitteln kann, wie viele Abhängigkeiten "zu viele" sind? Wie verhält es sich mit Metriken wie zyklomatische Komplexität, Kohäsion, Kopplung etc.?
Im Hinblick auf Ihre Frage, wie Sie es formuliert haben, ja, ist es. Aber es ist ein bisschen komplizierter, wenn Sie nach 6 Monaten zu diesem Code kommen, können Sie es in den ersten 2-3 Minuten nach dem Lesen des Codes? Müssen Sie andere Teile der Codebasis betrachten, um sie zu verstehen? Werden Änderungen an den Mitarbeitern erforderlich, um diese Klasse zu ändern? Kannst du diese Klasse einem anderen Ingenieur (besonders neuen Ingenieuren) in 2-4 Sätzen erklären? All dies hilft bei der Entscheidung.
Der Punkt, den ich versuche zu machen, ist, dass es hier immaterielle Werte gibt, die ebenfalls berücksichtigt werden sollten, bevor wir darüber entscheiden. Es ist eine Frage der Erfahrung, und es ist wichtig, zu lernen, wann man nicht allgemeingültige Regeln anwenden darf.
Tags und Links cyclomatic-complexity code-smell coupling cohesion