Die meisten Softwareentwickler lernen schon früh, dass direkter Objektbau durch den new-Operator eine Todsünde gegen die Flexibilität darstellt. Man impft uns ein, dass wir Abhängigkeiten hinter Abstraktionen verstecken müssen, um den Code testbar und erweiterbar zu halten. In diesem Bestreben greifen Heerscharen von Programmierern fast reflexhaft zum Factory Method Design Pattern Java, weil es als die saubere Lösung für Instanziierungsprobleme gilt. Doch wer jahrelang komplexe Enterprise-Systeme gewartet hat, stellt fest, dass dieser Reflex oft mehr Schaden anrichtet als er behebt. Wir bauen Kathedralen aus Interfaces und abstrakten Erzeugerklassen, nur um am Ende festzustellen, dass wir die Komplexität nicht eliminiert, sondern lediglich an einen Ort verschoben haben, an dem sie schwerer zu finden und noch schwerer zu verstehen ist.
Die Illusion der entkoppelten Architektur
Das Versprechen klingt verlockend: Eine Klasse soll nicht wissen, welche konkrete Implementierung sie erstellt, sondern diese Entscheidung an eine spezialisierte Methode delegieren. In der Theorie erlaubt das den Austausch von Logik ohne Eingriff in den Client-Code. In der Realität führt die exzessive Anwendung dieser Idee in Projekten oft zu einer regelrechten Klassen-Explosion. Für jedes Produkt braucht man plötzlich eine Fabrik, für jede Fabrik ein Interface und für jedes Interface eine Handvoll Implementierungen, die sich in Nuancen unterscheiden. Ich habe Systeme gesehen, in denen man durch fünf verschiedene Abstraktionsebenen springen musste, nur um herauszufinden, wo eigentlich ein simples Datenobjekt erzeugt wird. Das ist kein Gewinn an Flexibilität, sondern ein Verlust an Nachvollziehbarkeit. Lesen Sie mehr zu einem vergleichbaren Thema: diesen verwandten Artikel.
Die deutsche Ingenieurstradition neigt dazu, Dinge so gründlich zu planen, dass sie für jede Eventualität gerüstet sind. Das überträgt sich eins zu eins auf die Softwareentwicklung. Wir bauen eine Fabrik für Autoteile, obwohl wir genau wissen, dass wir in den nächsten zehn Jahren nur Reifen produzieren werden. Wer das Factory Method Design Pattern Java einsetzt, ohne eine echte, unmittelbare Notwendigkeit für Polymorphie bei der Erzeugung zu haben, betreibt Overengineering in Reinform. Es ist eine architektonische Versicherungspolice, deren Prämien in Form von technischer Schuld und kognitiver Last gezahlt werden, während der Schadensfall – der tatsächliche Austausch der Erzeugungslogik – oft niemals eintritt.
Warum das Factory Method Design Pattern Java oft ein Anti-Pattern ist
Wenn wir ehrlich sind, ist die Erzeugung von Objekten ein zentraler Aspekt der Geschäftslogik. Indem wir diese hinter einer Fabrikmethode verstecken, verschleiern wir die Intention des Programms. Ein erfahrener Entwickler möchte beim Lesen des Codes sofort sehen, was passiert. Ein expliziter Konstruktoraufruf ist ehrlich. Er sagt aus, was Sache ist. Eine Fabrik hingegen ist ein Versprechen, das erst zur Laufzeit eingelöst wird. Das macht statische Code-Analyse und Debugging unnötig kompliziert. In der Java-Welt hat sich zudem eine Kultur entwickelt, die das Vorhandensein von Entwurfsmustern mit Qualität gleichsetzt. Das führt dazu, dass Junior-Entwickler Fabriken bauen, weil sie glauben, dass professioneller Code so aussehen muss. Sie kopieren Strukturen aus Lehrbüchern, ohne zu hinterfragen, ob die damit gelösten Probleme in ihrem spezifischen Kontext überhaupt existieren. Netzwelt hat dieses wichtige Gebiet ebenfalls behandelt.
Joshua Bloch, eine Koryphäe der Java-Entwicklung, weist in seinem Standardwerk Effective Java darauf hin, dass statische Fabriken oft die bessere Wahl gegenüber dem klassischen Muster aus der Gang-of-Four-Ära sind. Dennoch halten sich die starren Hierarchien hartnäckig in den Köpfen. Das Problem ist die Verwechslung von Erweiterbarkeit mit Komplexität. Nur weil ich theoretisch in der Lage bin, eine neue Unterklasse meiner Fabrik einzuführen, bedeutet das nicht, dass mein System dadurch besser geworden ist. Oft ist das Gegenteil der Fall. Jede neue Ebene macht es schwieriger, den Datenfluss im Kopf zu visualisieren. Wir opfern die Lesbarkeit auf dem Altar der theoretischen Austauschbarkeit.
Der Mythos der einfacheren Testbarkeit
Ein häufig angeführtes Argument für die Auslagerung der Objekterzeugung ist die Testbarkeit. Man behauptet, dass Mock-Objekte nur dann sinnvoll eingesetzt werden können, wenn die Erzeugung entkoppelt ist. Das stimmt zwar im Kern, aber das Factory Method Design Pattern Java ist dafür selten das effizienteste Werkzeug. Moderne Dependency-Injection-Frameworks wie Spring oder Quarkus haben das klassische Fabrikmuster in weiten Teilen obsolet gemacht. Sie übernehmen die Verwaltung der Lebenszyklen und die Bereitstellung von Abhängigkeiten viel eleganter, als es eine handgeschriebene Fabrikstruktur jemals könnte.
Skeptiker werden nun einwenden, dass man sich nicht von Frameworks abhängig machen darf und die reine Lehre der objektorientierten Programmierung den Vorrang haben muss. Dieses Argument vernachlässigt jedoch die ökonomische Realität der Softwareentwicklung. Die Zeit, die wir damit verbringen, redundante Fabrik-Strukturen zu schreiben und zu warten, fehlt uns bei der Implementierung echter Features. Wir schreiben Code für den Code, nicht für den Anwender. In einem gut strukturierten System sollte die Erzeugung von Objekten so nah wie möglich an ihrer Verwendung liegen, es sei denn, es gibt einen zwingenden Grund für eine Abstraktion. Die Fabrikmethode sollte die Ausnahme sein, nicht der Standard. Wenn du merkst, dass du mehr Zeit damit verbringst, die Infrastruktur für deine Objekte zu bauen als die Objekte selbst, läuft etwas gewaltig schief.
Die kognitive Last der Abstraktion
Jeder Entwickler hat nur eine begrenzte Kapazität, komplexe Zusammenhänge gleichzeitig im Kopf zu behalten. Abstraktionen sind dazu da, diese Last zu senken, indem sie Details verbergen. Aber das Factory Method Design Pattern Java erreicht oft das Gegenteil. Es zwingt mich, mich mit der Hierarchie der Erzeuger auseinanderzusetzen, bevor ich überhaupt zum eigentlichen Produkt gelange. In großen Projekten führt das zu einer Fragmentierung des Wissens. Man weiß zwar, wie man eine Fabrik benutzt, aber niemand versteht mehr, was sie im Hintergrund eigentlich tut. Das ist gefährlich. Es führt zu Fehlern, die erst spät in der Produktion auftreten, wenn die dynamische Bindung nicht das liefert, was der Entwickler erwartet hat.
Echte Professionalität zeigt sich nicht darin, wie viele Entwurfsmuster man in einer Klasse unterbringen kann. Sie zeigt sich darin, wie einfach und direkt ein Problem gelöst wird. Wer eine Fabrik baut, baut eine Mauer. Manchmal ist diese Mauer als Schutz sinnvoll. Meistens steht sie aber einfach nur im Weg und versperrt die Sicht auf das Wesentliche. Wir müssen lernen, dem Drang zu widerstehen, alles in generische Strukturen zu pressen. Ein direkt instanziertes Objekt ist kein Zeichen von Unwissenheit, sondern oft ein Zeichen von Klarheit und Selbstbewusstsein. Wir sollten die Fabrik erst dann auspacken, wenn die Alternative ein unübersichtliches Chaos aus bedingten Anweisungen wäre, das sich anders nicht mehr bändigen lässt. Bis dahin ist Schlichtheit die höchste Form der Raffinesse.
Softwarearchitektur ist kein Selbstzweck, sondern ein Werkzeug zur Bewältigung von Komplexität, das bei falscher Handhabung selbst zur größten Komplexitätsquelle wird.
