Definition „Anti Pattern“ Was sind Anti-Pattern?

Mithilfe von Design Patterns lassen sich im Design gewisse Regeln ableiten, die als Guidelines für besseres Design dienen. Dabei geht es auch um das Vermeiden von systemischen Fehlern, zu diesen zählen auch die sogenannten Anti-Patterns.

Häufig auftretende Probleme lassen sich oft mit ganz gewöhnlichen Strategien lösen, man spricht hier in der Softwareentwicklung von Design Patterns. Das funktioniert selbst dann, wenn diese Lösungen selbst ineffektiv sind und ungewünschte Nebenwirkungen haben können.

In solchen Fällen spricht man vom sogenannten Anti-Pattern: Die Lösung eines Problems ist hier also selbst ein Problem, kommt aber dennoch weiterhin zum Einsatz. Dies ist der Fall, weil die Problemlösung zunächst nach einer adäquaten Lösung aussieht und das Problem auch tatsächlich zu lösen vermag. Die ungewünschten Konsequenzen sind eine Nachwirkung, an die im Vorfeld kaum gedacht wird.

Doch um in der Design-Pattern-Theorie auch wirklich als Anti-Pattern zu gelten, muss noch eine andere Bedingung erfüllt sein. Es gibt eine bessere, effektivere Lösung, die wiederholt und zuverlässig eingesetzt werden kann, aber nicht eingesetzt wird.

Das Konzept der Anti-Pattern kommt ursprünglich aus dem Development und geht auf Andrew Koenig und das Buch „Design Patterns“ (1995) zurück. Inzwischen hat sich der Begriff auch im Software Engineering oder im Projektmanagement eingebürgert.

Anti-Pattern am Beispiel besser verstehen

Die Design Patterns werden von Entwicklerinnen und Entwicklern als generelle Lösungen für häufige Probleme genutzt und gelten als positives Beispiel für die Lösung eines Problems. Ein Pattern ist dabei wiederholbar und effektiv.

Für Anti-Pattern gilt dies nicht, die fehlende Effektivität macht sich häufig in Form von technischen Schulden bemerkbar und sorgt so verspätet für höhere Kosten, langwieriges Refactoring oder einem insgesamt wenig attraktiven Code. Am besten lassen Anti-Pattern in der Entwicklung sich beim Betrachten einiger Beispiele verstehen.

Spaghetti-Code

Ein Programm, das sich im Wachstum befindet und stetig neue Funktionen bekommt, wächst auch im Code relativ schnell an. Es ist eine verführerische Lösung, Code einfach weiter zu schreiben und beliebig zu kopieren, ohne auf eine adäquate Modularisierung zu achten.

Der Spaghetti-Code löst gewissermaßen das Problem, indem neue Funktionen implementiert werden können und bis zu einem Punkt wird dies auch gutgehen. Allerdings entsteht so ein fragiles und unübersichtliches Gebilde, das vor allem für externe Hilfe nur schwer zu überblicken ist.

Boat Anchor

Nicht alle Funktionen müssen sofort in einem Programm enthalten sein, oftmals sollen diese erst in Zukunft hinzugefügt werden. Um die Funktionen später einzufügen, werden bereits beim initialen Schreiben des Codes einige Zeilen hinzugefügt, die später vielleicht einmal benötigt werden könnten. Diese dienen also als Bootsanker.

Ob der Code nun aber in Zukunft tatsächlich eingefügt wird oder ob beim Betrachten des Codes einfach nur enigmatische Zeilen ihr Unwesen treiben, der Code ist durch die Boat Anchor unnötig aufgebläht.

Dead Code

Toter Code ist mit dem Boat Anchor vergleichbar, nur dass er nicht für die Zukunft eingeplant ist, sondern aus einer früheren Programmversion stammt. Dead Code hatte einmal einen Zweck, doch die Funktionen wurden entfernt oder nie fertiggestellt und nun ist der Code immer noch aufgebläht und funktionslose Codezeilen blähen das Programm auf.

God Class

Die God Class ist ein häufig auftretendes Problem und ebenfalls ein Anti-Pattern. Während Klassen auf einzelne Verantwortlichkeiten beschränkt bleiben sollten, übernimmt die Gottklasse so viel sie kann.

In der Regel wurden beim Coden Shortcuts genommen und anstatt neue Klassen zu erstellen, wurden mehr Aufgaben an eine bereits bestehende Klasse übertragen. Auch dies löst zunächst ein Problem, ist aber eine sehr ineffiziente Lösung und sorgt irgendwann für eine wartungsresistente Klasse.

Anti-Pattern erkennen und vermeiden

Nicht jede ineffektive Problemlösung ist gleich ein Anti-Pattern. Wenigstens drei Mal sollte eine solche „Problemlösung“ auftreten, um aus ihr tatsächlich ein Muster ableiten zu können.

Genau wie Patterns auch bringen Anti-Patterns aber einen positiven Nebeneffekt, denn aus Mustern lässt sich am besten lernen. Wenn etwas immer Probleme verursacht, dann lässt sich im Design zuverlässig vorhersagen, dass es wieder Probleme verursachen wird - und es kann vermieden werden.

Andrew Koenig hatte in „Design Patterns“ übrigens bereits eine scharfe und eingängige Formulierung für die Definition von Anti-Pattern: „Ein Anti-Pattern ist mit einem Pattern vergleichbar, nur dass es statt einer Lösung etwas bietet, das oberflächlich nach einer Lösung aussieht, aber keine ist.“

Unglaublich hilfreich sind Anti-Pattern aber auch aufgrund eines häufig übersehenen Teils ihrer Definition: Es gibt eine effektivere und wiederholbare Lösung. Der Einsatz einer suboptimalen Lösung ohne Alternative stellt kein Anti-Muster dar. Lediglich dann ist das Anlegen von technischen Schulden (ob aus Zeitmangel, fehlender Qualifikation oder als Fortführen einer Altlast), wenn es alternative Methoden gibt, die ungenutzt bleiben.

(ID:48623532)