Dependency Injection hat sich durchgesetzt. Das muss also nicht mehr diskutiert werden. Es gibt zwar noch alte Projekte, die anders arbeiten (davon gibt es massig, denn auch in der Vergangenheit waren wir Programmierer ja nicht faul sondern haben Software geschrieben) – aber neuere Entwicklungen kommen selten ohne aus.

Leider gibt es noch oft Diskussionen, ob die DI via Property (also Setter-Methoden) oder den Konstruktor gehen soll. In den meisten Softwareprojekten sieht man ausschließlich Property-Injection (also einen Default-Konstruktor sowie ganz viele Setter). Dabei wird leider eine aus meiner Sicht grundlegende Regel vergessen: nach dem Konstruktor soll das Objekt minimal lauffähig sein. Dass heißt, dass alle verpflichtenden Informationen vorhanden sein müssen.

Oder anders ausgedrückt: in den seltensten Fällen ist ein Default-Konstrutor ausreichend für ein funktionierendes Objekt. Demnach spricht vieles für eine konstruktorbasierte DI.

Aber auch hier greift es zu kurz: der Konstruktor sollte ein minimal lauffähiges Objekt erzeugen. Und einige DI-Dependencies werden hier nicht benötigt. Diese Abhängigkeiten sollen also nicht in den Konstruktor. Und da spricht ja auch nichts dagegen: die absolut notwendigen Abhängigkeiten kommen in den Konstruktor, die optionalen Abhängigkeiten in Properties.

Oft wird angeführt, dass das weit verbreitete (und oft auch von mir genutzte) Spring-Framework keine Konstruktor-DI unterstützen würde oder die Entwickler von Konstruktor-DI abraten würden, aber wie der Blogeintrag http://spring.io/blog/2007/07/11/setter-injection-versus-constructor-injection-and-the-use-of-required/ schon 2007 beschrieb, sehen das unsere  Kollegen von Pivotal auch so wie hier beschrieben.

Voilà, das Problem ist sauber gelöst. Ohne Religionskrieg.

Im Netz wurde schon sehr viel geschrieben, wie man Objekte erschaffen kann. Es ist eines der Grundprobleme bei der Softwareentwicklung und wie bei vielen wichtigen Entscheidungen gibt es eine klare Antwort: Es kommt auf die Situation an.

Weiterlesen

Fast alle Softwareentwickler sind sich einig, dass Quellcode lesbar sein soll und für andere Entwickler möglichst lesbar sein soll.

Was allerdings als lesbar und leicht verständlich ist, ist nicht immer so eindeutig. Neben den vereinbarten Styleguides und den eigenen Vorlieben gibt es dann noch andere Kriterien.

Weiterlesen