Ich habe in Spring Boot seit etwas mehr als einem Jahr entwickelt, aber die Vorteile der Verwendung eines Autowired-Konstruktors noch nicht verstanden und mich gefragt, ob jemand dies könnte Erklären Sie mir dies und was als Best Practice angesehen wird.
Nehmen wir an, ich habe eine Bean wie folgt:
@Component public class MyBean { void doSomeStuff() { } } Und ich habe eine Dienst, der von dieser Bean abhängig ist
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } Für mich besteht die einfachste Möglichkeit, die Abhängigkeit in diese Klasse einzufügen, darin, die Variable einfach mit @Autowired zu versehen
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Es gibt jedoch auch andere Online-Stellen (und auch andere Entwickler in meinem Team), die einen solchen Ansatz bevorzugen:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } Für mich ist die Verwendung eines solchen Konstruktors einfach redundanter Code. Das automatische Verdrahten der Bean ist viel einfacher und unkomplizierter als das, was mir als Boilerplate-Code erscheint.
Kommentare
-
To me, using a constructor like that is simply redundant code. Autowiring the bean is much simpler and straightforward than what appears to me to be boilerplate code.und sind Sie nicht besorgt über die Magie, eine Bohne in eine Instace-Variable zu injizieren, die privat ist und keinen Setter hat? Sind Sie nicht besorgt über die enorme technische Verschuldung, die dies für Sie, Ihre Mitarbeiter, verursacht? Sind Sie nicht besorgt darüber, zu viel auf das magische Paradigma von Spring ‚ zu übertragen, anstatt bewährte Verfahren zu entwerfen? - Sind Sie nicht besorgt darüber, anderen zu erlauben, eine Instanz zu erstellen von MyServiceImpl ohne die fällige Abhängigkeitsinjektion?
- ‚ ist nicht, dass ich ‚ nicht “ betroffen „, ‚ war ich nicht ‚ Ich weiß nicht, wie dies zu einer enormen technischen Verschuldung führte. Wenn Sie ein Beispiel dafür geben könnten, warum es ‚ so schlecht ist, würde ich ‚ es schätzen.
- “ Sind Sie nicht besorgt darüber, zu viel über das magische Paradigma des Frühlings ‚ zu berichten, anstatt bewährte Verfahren zu entwerfen? “ Gibt es Ressourcen zu guten Entwurfspraktiken, die für diese Diskussion relevant sind und die Sie empfehlen können? Ich ‚ würde sie gerne lesen.
- Siehe hier: stackoverflow.com/questions/34580033/ …
Antwort
Sie verwenden a Realer Konstruktor aus den gleichen Gründen, aus denen Sie öffentliche Getter und Setter verwenden, anstatt private Variablen öffentlich zu machen.
Einige Beispiele aus der Praxis: Mobiltelefone sind an sicheren, informationsempfindlichen physischen Standorten nicht zulässig. Jede Kommunikation mit diesem sicheren Ort muss über ein sicher eingerichtetes, kontrolliertes und verschlüsseltes Kommunikationsprotokoll erfolgen, nicht heimlich durch einen nicht überwachten und unkontrollierten Schurken-Kommunikationskanal.
Bei einem Konzert dürfen Sie dies nicht zulassen Wirf Dinge über den Zaun zu jemandem, der bereits im Stadion ist. Alles, was rein oder raus kommt, muss durch ein Tor gehen.
Wenn das alles ist, was Ihr Codebeispiel enthält, dann sieht es wie eine unnötig ausführliche Boilerplate aus. Aber häufig machen wir im Konstruktor neben der Einstellung auch andere Dinge Private Variablen wie Validierung. In vielen Programmiersprachen ist das Ändern der Art und Weise, wie Sie dies nachträglich tun, eine binäre Unterbrechungsänderung, Daher kann es ein sinnvoller Schritt sein, den Konstruktor im Voraus bereitzustellen.
Schließlich sollte die Klasse in der Lage sein, unabhängig von der Abhängigkeitsinjektion zu funktionieren. Wenn Sie einem privaten Mitglied eine Anmerkung hinzufügen, aber keinen Konstruktor einschließen Sie haben diese Klasse im Wesentlichen fest an den DI-Container gebunden, und die Klasse funktioniert ohne sie nicht.
Kommentare
- “ Bei einem Konzert erlauben Sie ‚ nicht, dass Leute Dinge über den Zaun zu jemandem werfen, der ‚ s schon im stadiu m. Alles, was rein oder raus kommt, muss durch ein Tor gehen. “ Aber ich sehe ‚ nicht, wie die Verwendung eines Konstruktors die automatische Verdrahtung sicherer macht? Wenn es keine Konstruktoranforderungen (wie die Validierung) gäbe, wäre es dann von Vorteil, einen Konstruktor zu verwenden?
- Sie ermöglichen es, die Validierung später hinzuzufügen, ohne die Binärkompatibilität zu beeinträchtigen.
- Außerdem Beachten Sie, dass private Mitglieder wirklich privat bleiben sollten. Das ‚ ist irgendwie der springende Punkt, private Mitglieder zu haben.
- Der springende Punkt ist, bewährte Designpraktiken zuzulassen, die mit @Autowire kompatibel sind. Konstruktoren zu haben ist die natürlichste Sache in OOP. Das Gegenteil (was Sie einfach und einfacher nennen) ist ein bisschen beängstigend. Das Entfernen von Konstruktoren bietet keine wirklichen Vorteile, da ‚ überhaupt keine Einfachheit vorliegt. Konstruktoren gehören zu den einfachsten Methoden in OOP.Per se haben sie normalerweise eine sehr geringe Komplexität, die es wert ist, die Magie von Spring IoC
- zu implementieren. Für das, was es ‚ wert ist, ist Java in der Regel ein sowieso sehr ausführliche Sprache. Wenn Sie ‚ versuchen, einen Teil dieser Ausführlichkeit zu zähmen, ist es unwahrscheinlich, dass das Eliminieren von Konstruktoren eine große Beeinträchtigung darstellt.