Ich habe gerade eine Java-Anwendung geerbt und nach Inspektion des Codes sehe ich, was IMHO eine Bastardisierung des Spring-Frameworks ist. Sie sehen, das Java-Team scheint eine Abneigung gegen Schnittstellen zu haben, also enden wir mit solchen Dingen:
%Vor%Es gibt keine Spring-Konfiguration, keine Bean definiert, keine Chance, dass ich das enthaltene Objekt isoliert testen kann. Dies ist im Wesentlichen eine Annotation-basierte Fabrik mit dem Overhead von Spring.
Bin ich out-of-line, oder ist das wie eine Elefantenpistole zu verwenden, um Fliegen zu töten? Ich muss nur einen Reality-Check haben, weil alle anderen im Team denken, dass das vollkommen akzeptabel ist.
Bearbeiten In vielen Fällen erscheinen diese annotierten Fabriken in komplexen Verarbeitungsklassen, die immens von isolierten Tests profitieren würden. Das Team runzelt jedoch auch beim Testen.
Es gibt kein Geheimnis hier, hoffe ich. Wenn ich eine konkrete Klasse habe, die nicht hinter einer Schnittstelle steht, und es gibt keine entsprechende Spring-Bean, um das Objekt "einzurichten", dann ist es unbestreitbar eine verklärte Fabrik, die mit 10 Codezeilen implementiert werden kann.
Spring wird auf keine andere Weise im System verwendet; Das ist es.
Meine Ziele jetzt:
Ich schätze, die letzte Frage ist: Hat es einen Nutzen, diese Felder mit Autowired zu versehen, wenn wir das Framework nicht testen oder auf andere Weise nutzen? Ich würde auch new das Objekt, wenn die Abhängigkeit unveränderlich ist.
Es ist sicherlich begrenzt, was möglich ist, aber es ist auch keine totale Zeitverschwendung.
Da es sich bei dem fraglichen Typ um final handelt, kann er nicht einfach für isolierte Tests gespottet werden.
Instanzen dieses Typs können jedoch immer noch über ihre Eigenschaften in hohem Maße konfigurierbar sein. Wenn Sie Spring verwenden, um eine zur Laufzeit ordnungsgemäß konfigurierte Instanz zu injizieren, wird die enthaltene Klasse enorm vereinfacht. Die Klasse kann sich auf ihre Verantwortlichkeiten konzentrieren und sich auf Spring verlassen, um sie mit den Mitarbeitern auszustatten, die sie braucht.
Schnittstellen werden verwendet; Dies könnte eine Antwort darauf sein. Ich denke, dass, beginnend mit endgültigen, konkreten Klassen für viele Arten, die Verwendung von leicht verfügbaren Refactoring-Tools, um später Schnittstellen zu extrahieren, wenn ein spezifischer Bedarf identifiziert wird, in vielen Kontexten eine vertretbare Position ist.
Ich stimme Ihnen zu, dass dies ein Missbrauch dessen ist, was Spring tun kann (im Gegensatz zu dem, was Spring SOLL tun sollte). Ist die Person, die die Anwendung entworfen hat, so herum? Es wäre interessant zu hören, warum sie so eine Anwendung erstellen.
Ich habe gerade eine Java-Anwendung geerbt und nach Inspektion des Codes sehe ich, was IMHO eine Bastardisierung des Spring-Frameworks ist. Sie sehen, das Java-Team scheint eine Abneigung gegen Schnittstellen zu haben, also enden wir mit solchen Dingen:
%Vor%Es gibt keine Spring-Konfiguration, keine Bean definiert, keine Chance, dass ich das enthaltene Objekt isoliert testen kann. Dies ist im Wesentlichen eine Annotation-basierte Fabrik mit dem Overhead von Spring.
Bin ich out-of-line, oder ist das wie eine Elefantenpistole zu verwenden, um Fliegen zu töten? Ich muss nur einen Reality-Check haben, weil alle anderen im Team denken, dass das vollkommen akzeptabel ist.
Bearbeiten In vielen Fällen erscheinen diese annotierten Fabriken in komplexen Verarbeitungsklassen, die immens von isolierten Tests profitieren würden. Das Team runzelt jedoch auch beim Testen.
Es gibt kein Geheimnis hier, hoffe ich. Wenn ich eine konkrete Klasse habe, die nicht hinter einer Schnittstelle steht, und es gibt keine entsprechende Spring-Bean, um das Objekt "einzurichten", dann ist es unbestreitbar eine verklärte Fabrik, die mit 10 Codezeilen implementiert werden kann.
Spring wird auf keine andere Weise im System verwendet; Das ist es.
Meine Ziele jetzt:
Ich schätze, die letzte Frage ist: Hat es einen Nutzen, diese Felder mit Autowired zu versehen, wenn wir das Framework nicht testen oder auf andere Weise nutzen? Ich würde auch main das Objekt, wenn die Abhängigkeit unveränderlich ist.
Es ist sicherlich begrenzt, was möglich ist, aber es ist auch keine totale Zeitverschwendung.
Da es sich bei dem fraglichen Typ um %code% handelt, kann er nicht einfach für isolierte Tests gespottet werden.
Instanzen dieses Typs können jedoch immer noch über ihre Eigenschaften in hohem Maße konfigurierbar sein. Wenn Sie Spring verwenden, um eine zur Laufzeit ordnungsgemäß konfigurierte Instanz zu injizieren, wird die enthaltene Klasse enorm vereinfacht. Die Klasse kann sich auf ihre Verantwortlichkeiten konzentrieren und sich auf Spring verlassen, um sie mit den Mitarbeitern auszustatten, die sie braucht.
Schnittstellen werden verwendet; Dies könnte eine Antwort darauf sein. Ich denke, dass, beginnend mit endgültigen, konkreten Klassen für viele Arten, die Verwendung von leicht verfügbaren Refactoring-Tools, um später Schnittstellen zu extrahieren, wenn ein spezifischer Bedarf identifiziert wird, in vielen Kontexten eine vertretbare Position ist.
Ich kann nicht sagen, dass ich den Punkt vollständig verstehe. Schließlich würden wahrscheinlich ein paar Codezeilen das System in einer %code% -Methode verkabeln und Sie hätten dann keine Abhängigkeit von Spring.
Und ja, ich stimme zu, dass es nicht sinnvoll ist, Schnittstellen nicht zu injizieren. Ich tendiere nicht dazu, eine große Anzahl von Komponententests durchzuführen, aber trotzdem würde ich später Flexibilität bei der Änderung von Implementierungen verlieren (oder unterschiedliche Implementierungen von Klassen in verschiedenen Implementierungen haben - z. B. Integrationstests).
Es tut mir leid, aber ich kann nicht sagen, ob dies ein Missbrauch von Spring ist, basierend auf den zwei Codezeilen, die Sie gepostet haben, und ich bezweifle, dass dies auch jemand anders kann.
Wenn Sie sich darüber beschweren, dass der statische Typ dieses Objekts keine Schnittstelle ist, haben Sie vielleicht einen Punkt. Aber selbst das ist schwer aus dieser einzelnen Codezeile zu erkennen. Ist das wirklich eine Service- oder Repository-Klasse ohne Schnittstelle? Wenn ja, stimme ich zu. Wenn nicht, müsste ich mehr wissen.
Wenn dein Team das Testen missbilligt, ist das schade. Ich hätte gedacht, dass einer der Gründe für Spring darin besteht, das Testen zu erleichtern.
Vielleicht haben Sie einen Punkt, aber ich kann mir Ihrer ursprünglichen Frage nicht sicher sein. Vielleicht können Sie detaillierter bearbeiten.
Wenn dies ein Beispiel dafür ist, wie Sie mit Ihren Teamkollegen kommunizieren, wären sie vielleicht gerechtfertigt, wenn sie sagten, dass Sie sich nicht gut genug erklärt haben. Stellen Sie sicher, dass Sie hier nicht nur für Selbstüberhöhung sind.
Es tut mir leid, aber ich kann nicht sagen, ob dies ein Missbrauch von Spring ist, basierend auf den zwei Codezeilen, die Sie gepostet haben, und ich bezweifle, dass dies auch jemand anders kann.
Wenn Sie sich darüber beschweren, dass der statische Typ dieses Objekts keine Schnittstelle ist, haben Sie vielleicht einen Punkt. Aber selbst das ist schwer aus dieser einzelnen Codezeile zu erkennen. Ist das wirklich eine Service- oder Repository-Klasse ohne Schnittstelle? Wenn ja, stimme ich zu. Wenn nicht, müsste ich mehr wissen.
Wenn dein Team das Testen missbilligt, ist das schade. Ich hätte gedacht, dass einer der Gründe für Spring darin besteht, das Testen zu erleichtern.
Vielleicht haben Sie einen Punkt, aber ich kann mir Ihrer ursprünglichen Frage nicht sicher sein. Vielleicht können Sie detaillierter bearbeiten.
Wenn dies ein Beispiel dafür ist, wie Sie mit Ihren Teamkollegen kommunizieren, wären sie vielleicht gerechtfertigt, wenn sie sagten, dass Sie sich nicht gut genug erklärt haben. Stellen Sie sicher, dass Sie hier nicht nur für Selbstüberhöhung sind.