Java >> Java Tutorial >  >> Java

Warum habe ich meine Meinung zur Feldinjektion geändert?

Früher war ich ein großer Fan der Feldinjektion.

Aber eines Tages fing ich an, mich selbst zu hinterfragen. Kann es sein, dass ich mich geirrt habe?

Lassen Sie uns herausfinden, was passiert ist.

Kann es zu einfach sein?

Ich war mir natürlich der Tatsache bewusst, dass Feldinjektion versus Konstruktorinjektion versus Setterinjektion ein ziemlich heißes Thema ist.

Ich war mir auch der Vor- und Nachteile jedes Ansatzes bewusst. Das Problem war, dass diese Argumente für mich auf einer tieferen Ebene keine Resonanz fanden.

Die Vorteile jedes Ansatzes schienen klar und gleichzeitig etwas zu akademisch. Vielleicht war ich nicht bereit dazu wirklich verstehe sie noch.

Um die Sache noch schlimmer zu machen, dachte ich wirklich, dass ich das gute Zeug der Feldinjektion bekommen könnte und all das schlechte Zeug auf magische Weise verschwinden würde.

Ich stimme zu. Ich war ein arrogantes Arschloch.

Trotzdem setzte ich die Feldinjektion fort. Wieso den? Finden wir es heraus.

Ich habe eine Dienstklasse erstellt, die Feldinjektion verwendet. Sein Quellcode sieht wie folgt aus:

@Service
public class PersonServiceImpl implements PersonService {

	@Autowired
	Private PersonRepository repository;

}

Der Grund, warum ich die Feldinjektion der Konstruktorinjektion vorgezogen habe, war, dass sie viel einfacher aussieht als die Konstruktorinjektion. Dieselbe Dienstklasse, die die Konstruktorinjektion verwendet, sieht wie folgt aus:

@Service
public class PersonServiceImpl implements PersonService {

	private final PersonRepository repository;

	@Autowired
	public PersonServiceImpl(PersonRepository repository) {
		this.repository = repository;
	}
}

Es sieht nicht sehr sauber oder elegant aus. Recht?

Warte, es wird noch besser. Was ist, wenn ich meiner Serviceklasse einige Abhängigkeiten hinzufüge?

Wenn ich Feldinjektion verwende, sieht meine Serviceklasse immer noch sauber aus:

@Service
public class PersonServiceImpl implements PersonService {

	@Autowired
	private PersonRepository repository;

	@Autowired 
	Private ServiceA serviceA;

	@Autowired
	Private ServiceB serviceB;
}

Wenn ich dagegen die Konstruktorinjektion verwende, sieht der Quellcode meiner Serviceklasse wie folgt aus:

@Service
public class PersonServiceImpl implements PersonService {

	private final PersonRepository repository;

	private final ServiceA serviceA;

	private final ServiceB serviceB;

	@Autowired
	public PersonServiceImpl(PersonRepository repository, ServiceA serviceA, ServiceB serviceB) {
		this.repository = repository;
		this.serviceA = serviceA;
		this.serviceB = serviceB;
	}
}

Ziemlich furchtbar. Recht?

Mein größtes Problem mit der Konstruktorinjektion war, dass die Konstruktoren sehr unordentlich werden, wenn meine Klasse viele Abhängigkeiten hat.

Dann habe ich diesen Tweet von Oliver Gierke gelesen (Lesen Sie die ganze Diskussion):

Feldinjektionen sind böse… verstecken Abhängigkeiten, anstatt sie explizit zu machen.

Ich fing an, über diesen Tweet nachzudenken, und irgendetwas machte in mir klick. Ich verstand, dass ich einen wichtigen Schritt übersprungen habe, weil es so einfach war, neue Abhängigkeiten auf "saubere und elegante" Weise zu meinen Klassen hinzuzufügen.

Es ist ein Zeichen

Als ich Feldinjektion verwendet habe und meiner Klasse eine neue Abhängigkeit hinzufügen musste, habe ich diese Schritte befolgt:

  1. Fügen Sie der Klasse ein neues Feld hinzu und kommentieren Sie es mit @Autowired Anmerkung.
  2. Schreiben Sie den Code, der die hinzugefügte Abhängigkeit verwendet.

Dieser Ansatz schien sauber und elegant, aber leider hatte ich eine sehr wichtige Sache missverstanden. Ich dachte, dass die Konstruktorinjektion Konstruktoren unordentlich und hässlich aussehen lässt. Das war ein großer Fehler.

Ein chaotischer Konstruktor ist ein Zeichen. Es warnt mich, dass meine Klasse zu einem Monolithen wird, der ein Alleskönner und ein Meister von nichts ist. Mit anderen Worten, ein chaotischer Konstruktor ist eigentlich eine gute Sache. Wenn ich das Gefühl habe, dass der Konstruktor einer Klasse zu chaotisch ist, weiß ich, dass es an der Zeit ist, etwas dagegen zu unternehmen.

Ich weiß, dass Feldinjektion und Konstruktorinjektion auch andere Unterschiede aufweisen. Für mich ist jedoch mein Hass auf chaotische Konstruktoren am wichtigsten, weil er mich dazu gebracht hat, die anderen Unterschiede zu studieren und zu verstehen (auf die einen kommt es an).

Ich hoffe, dass es für Sie dasselbe tun wird.

Wichtige Unterschiede

Ich werde nicht über die Unterschiede zwischen Feldinjektion, Setterinjektion und Konstruktorinjektion schreiben. Stattdessen gebe ich Ihnen Links zu Blogbeiträgen, die ich interessant und nützlich fand.

Diese Blogbeiträge sind:

  • Wiederholung nach mir:Setter-Injektion ist ein Symptom für Designprobleme. Dieser Blogbeitrag hat einen ziemlich provokativen Titel, aber er macht einen guten Job, um auf die Probleme der Setter-Injektion hinzuweisen.
  • Der einzig richtige Weg zur Abhängigkeitsinjektion. Dies ist ein weiterer Blogbeitrag von Jens Schauder und "überraschenderweise" befürwortet er auch die Konstruktorinjektion. Das Beste an diesem Blogbeitrag sind seine Kommentare. Ich empfehle Ihnen, sich den Kommentar von Oliver Gierke anzusehen, da er einige großartige Einblicke enthält.
  • Ich habe mich geirrt:Constructor vs. Setter-Injektion. Dies ist ein Blogbeitrag von Steve Schols und beschreibt, warum die Setter-Injektion der Konstruktor-Injection vorzuziehen ist.
  • Setter-Injektion versus Konstruktor-Injektion und die Verwendung von @Required. Dieser (ziemlich alte) Blogbeitrag enthält einige wirklich interessante Dinge. Eine davon ist, dass es den Unterschied zwischen Anwendungscode und Framework-Code beschreibt und darüber spricht, wie sich dies auf die Auswahl der verwendeten Dependency-Injection-Methode auswirkt.
  • Setter-Injektion ist scheiße. Dieser Blogbeitrag beschreibt, warum Setter-Injektionen unbedingt vermieden werden sollten. Der Grund, warum ich es hier hinzugefügt habe, ist, dass der Autor die gleichen ersten Gedanken zur Konstruktorinjektion hatte wie ich.
  • Dieser Abhängigkeitsinjektionswahnsinn muss ein Ende haben! Dies ist ein Blogbeitrag von Johannes Brodwall. Es spricht über die Probleme der Abhängigkeitsinjektion. Denken Sie daran, die Kommentare zu diesem Beitrag zu lesen. Wenn Sie daran interessiert sind, etwas zum Nachdenken zu bekommen, empfehle ich Ihnen, mit der Lektüre seines Blogs zu beginnen. Er hat viele gute Sachen drin.

Habe ich etwas verpasst?


Java-Tag