© StonePictures/Shutterstock.com
Kolumne: EnterpriseTales

Kolumne: EnterpriseTales


Der Kern von objektorientierter Programmierung ist die Kapselung von Daten und den darauf operierenden Methoden. Das macht Objektorientierung zu einem guten Kandidaten, um Businesslogik zu implementieren, da diese ja in der Regel eine Verknüpfung von Daten und Operationen darstellt. Richtig angewendet, lassen sich sehr gut lesbare und wartungsfreundliche Businessanwendungen mit objektorientierter Programmierung schreiben.

Objektorientierung hat allerdings einen großen Nachteil. Sie ist von Grund auf statusbehaftet. Das wird zum Problem, wenn es um parallele Zugriffe geht. Parallele Zugriffe auf dasselbe Objekt lassen sich mit objektorientierter Programmierung nicht performant und gleichzeitig wartbar realisieren. Beim Versuch, das zu tun, entsteht eine Mischung aus Infrastrukturcode und Businesslogik. Eine Vermischung beider Aspekte erscheint natürlich nicht sinnvoll. Hinzu kommt, dass objektorientierte Programmierung generell nicht gut darin ist, Infrastrukturcode zu schreiben. Leider bestehen unsere Anwendungen nur zu einem Teil aus Businesslogik. Ein nicht unerheblicher Teil ist Infrastrukturcode.

In den vergangenen Jahren ist zu beobachten gewesen, dass sich die Enterprise-Java-Frameworks daranmachen, die Trennung von Infrastrukturcode und Businesslogik voranzutreiben. Vorreiter ist dabei nach wie vor das Spring-Framework, aber auch der Enterprise-Java-Standard zieht regelmäßig nach. Die Trennung hat das durchaus zu begrüßende Ziel, dass sich der allgemeine Entwickler auf die Implementierung der Businesslogik fokussieren kann, während das Framework die Infrastrukturlogik quasi unbemerkt im Hintergrund erledigt.

Das Ergebnis ist allerdings eine Flut von Annotations, hinter denen sich der Infrastrukturcode häufig so gut versteckt, dass dem Entwickler nicht klar ist, was dahinter tatsächlich passiert. Das wird natürlich dann zum Problem, wenn der Infrastrukturcode nicht so funktioniert wie vom Entwickler erwartet. Zudem kann es passieren, dass vor lauter Annotations die Businesslogik im Code nicht mehr wiederzufinden ist. Einige Leute sprechen angesichts der Annotation-Flut schon von der „Annotation Hell“, in Anlehnung an die „XML Hell“, die die Älteren unter uns noch aus J2EE-Zeiten kennen.

Auf die Spitze getrieben hat diesen Tatbestand Greg Young bereits in seiner Keynote zur QCon 2013 mit seinem Talk „8 Lines of Code“ [1]. Auch wenn sich die Keynote auf C#-Code bezog, lässt sie sich sehr gut auf Enterprise-Java-Code übertragen. Als Aufhänger nimmt You...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang