Suche
Eigene Design Patterns statt Anti-Pattern!

Spaghetti-Code? Nein danke! Eigene Design Pattern für besseren Code

Ann-Cathrin Klose

© Shutterstock.com/pada smith

Schlechter Code hat viele Namen: Spaghetti-Code, Poltergeister und Lava-Ströme sind nur drei Varianten der Anti-Patterns, die schlechten Code ausmachen. Wer aber sein eigenes Software Design Pattern entwickelt, kann viele dieser Probleme vermeiden.

Was sind Software Design Patterns überhaupt und wozu braucht man sie? Diese Frage ist alt und wird doch immer wieder diskutiert, wie eine schnelle Suche im Web zeigt. Bereits unter den Top 10 der Google-Suchergebnisse finden sich Resultate aus dem Jahr 2002 und 2016. Und so mancher Entwickler gibt darin zu, sich gar nicht so sicher zu sein, wie Design Patterns richtig eingesetzt werden.

Nützlich oder nutzlos?

Sind Design Patterns also eine unnötige Spielerei, die vielleicht von akademischer, aber nicht unbedingt realer Bedeutung sind? Definitiv nicht! Es geht um nicht weniger als guten Code – oder, ganz im Gegenteil, schlechten Code, wenn wir die Anti-Patterns betrachten. Spaghetti-Code kennt wohl jeder, der schon einmal mit Legacy-Anwendungen gearbeitet hat. Verschachtelt, unübersichtlich und strukturlos kommt diese Art des Codes daher und ist entsprechend unbeliebt unter Entwicklern. Oft erscheint es dann leichter, den Code ganz neu zu schreiben, statt ihn zu debuggen.

Lesen Sie auch: Softwarearchitektur für Innovation: Wie Software neue Umsatzquellen erschließen kann

Als Lava-Strom wird ein ähnliches Problem bezeichnet. Wenn beispielsweise ein neuer Manager ein Projekt übernimmt und nun etwas ganz anderes will als zuvor gemacht wurde, bleiben schnell Sackgassen im Code zurück. Code-Abschnitte, die auf eine frühere Projektversion zurückgehen und eigentlich nicht mehr gebraucht werden, bleiben einfach mal im Code. Niemand traut sich, sie einfach zu löschen. Man könnte ja eine Abhängigkeit übersehen oder den Code doch noch mal benötigen! Irgendwann ist die Code-Basis dann vollkommen aufgebläht und unüberschaubar. Die toten Code-Teile fügen mögliche Fehler und Probleme hinzu, die man sonst nicht hätte.

Gespenster im Code: Gruselige Anti-Patterns

Und Poltergeister? Das sind Bug-Fixes und schnelle Änderungen am Code, die zum Zeitpunkt ihrer Erstellung absolut sinnvoll waren. Irgendwann werden sie aber nicht mehr gebraucht, weil sie vielleicht nur dazu da waren, mal eben was auszuprobieren – sie bleiben aber im Code und verbrauchen bei jedem Aufruf wieder Ressourcen, weil sie unnötigerweise mit ausgeführt werden. Sie geraten einfach in Vergessenheit, bis keiner mehr weiß, wozu sie da waren.

Das Problem mit allen drei (und sicherlich noch vielen weiteren) Anti-Patterns ist also offensichtlich: Code wird verändert, ohne die langfristigen Folgen zu bedenken. Irgendwann ist der Code dann so unübersichtlich, dass niemand mehr weiß, welcher Abschnitt denn wofür zuständig ist. Und dann kann es eigentlich nur noch schlimmer werden.

Anfänger mögen Spaghetti

Eine Ursache für schlechten Code im Stil der vorgenannten Anti-Patterns ist ein Mangel an Erfahrung. Jeder fängt mal klein an und dass Anfänger erst einmal einige Fehler machen, gehört dazu. Wer bereits einige Male an Spaghetti-Code verzweifelt ist, wird sich davor hüten, den gleichen Fehler zu machen. Wer noch nie mit diesem Phänomen zu tun hatte, erkennt nicht ganz so leicht, dass er gerade dabei ist, solchen Code zu schreiben.

Auch interessant: Infografik: Software-Architektur-Trends 2016

Dagegen helfen Software Design Patterns. Die bekanntesten Patterns wurden von der Gang of Four definiert, mit dem Ziel, Entwicklern zu besserem Code zu verhelfen. Im Umgang mit den Patterns ist jedoch Vorsicht angebracht. Ein Design Pattern ist nämlich keinesfalls für jedes Problem geeignet; kein einzelnes Pattern sollte unreflektiert für den gesamten Code verwendet werden. Vielmehr handelt es sich bei Design Patterns um Lösungen für spezifische Schwächen bestimmter Programmiersprachen oder klar umrissene Probleme bei der Programmierung.

Design Pattern: Keine einzelne Lösung für alle Probleme

Das zeigt sich auch an der Vielfalt verfügbarer Design Patterns: Es gibt Empfehlungen, die auf bestimmte Programmiersprachen wie C# ausgerichtet sind und solche, die sich an Android-Entwickler richten; es gibt Diskussionen darüber, ob das Singleton-Pattern, bekannt aus dem Buch der Gang of Four, nun nicht eigentlich ein Anti-Pattern oder zumindest doch im Kontext der Dependency Injections heutzutage gar keine gute Wahl mehr ist. Dabei geht es im Kern jedoch zumeist um Fälle, die die goldene Regel der Arbeit mit Design Patterns missachten: Das richtige Pattern für den richtigen Zweck.

Wer überall und immer nur Singletons verwendet, macht ganz einfach etwas falsch. Das musste auch Muhammad Umair feststellen, der genau das getan hat. Das Singleton-Pattern, bei dem nur ein Objekt pro Klasse erlaubt ist, war das einzige ihm bekannte Design Pattern und musste somit für jedes Problem herhalten. Wie Umair erklärt, stellte er jedoch irgendwann fest, dass er Design Patterns eigentlich gar nicht richtig verstanden hatte.

Eigene Probleme – eigenes Pattern?

Aus dieser Erkenntnis entstand bei Umair der Gedanke an die Entwicklung eigener Design Patterns: Wenn Design Patterns nämlich dazu da sind, wiederkehrende Probleme bei der Software-Entwicklung zu lösen, kann es doch nur helfen, die eigenen Schwierigkeiten zu erkennen und auf diese Weise anzugehen!

Umair und viele andere Autoren empfehlen zu diesem Zweck die Verwendung eines Logbuchs im eigenen Arbeitsalltag: Alle wichtigen Gedanken zum eigenen Programmierstil, alle gelösten Bugs, alle erkannten Fehler werden notiert und nach wenigen Monaten ausgewertet. Die kleinen Muster des Alltags fallen so auf, auch wenn sie sonst eher untergehen würden. Daraus können dann eigene Patterns abgeleitet werden. Immer, wenn Problem X auftritt, wird Lösung Y angewendet; für die Funktionen, die einem besonders schwer fallen, könnte eine Datei mit Vorlagen angelegt werden. So werden eigene, negative Fehlermuster aufgedeckt und zukünftig vermieden.

Pattern oder nicht?

Aber ist das dann wirklich ein Design Pattern? Die Entwicklergemeinschaft im Netz ist sich uneinig: Manche lassen Design Patterns nur dann als solche gelten, wenn diese sich verbreiten und von vielen Menschen genutzt werden. Andere erkennen jedes wiederkehrende Muster als Pattern an, das in der Entwicklung genutzt wird, um Fehler zu vermeiden.

Lesen Sie auch: Knigge für Softwarearchitekten: Fortschritt oder Verschlimmbesserung?

So oder so geht es im Kern jedoch um besseren Code, unabhängig davon, wie man das gerade eingesetzte Muster nun nennen möchte. Insbesondere Anfänger können also sehr davon profitieren, ihr eigenes Programmierverhalten einmal kritisch und langfristig unter die Lupe zu nehmen und sich ihre Schwächen bewusst zu machen. Man möchte ja nicht als Autor von Spaghetti-Code bekannt werden!

Gute Design Patterns, guter Code

Die Arbeit mit eigenen Mustern kann außerdem dabei helfen, langfristig die richtigen Software Design Patterns zu nutzen, die von anderen Menschen bereits definiert und dokumentiert wurden. Statt eigene Patterns zu entwickeln, kann anhand eines Logbuchs nämlich auch eine gezielte Auswahl aus der großen Vielfalt von Software Design Patterns getroffen werden, die zu den eigenen Problemen passt. So entgeht man der „one Pattern fits all“-Falle und vergeudet keine Zeit damit, die falschen Muster zu erlernen. Vielmehr kann man auf diese Weise die eigenen Erkenntnisse um reproduzierbare, getestete und verlässliche Hilfestellungen von Außen ergänzen.

Wenn von Software Design Patterns die Rede ist, geht es also nicht unbedingt nur um das Buch der Gang of Four. Es geht auch nicht nur um die Frage, ob Singletons heutzutage veraltet sind. Es geht um das Erkennen eigener Schwächen und die Frage, wie sich diese so auflösen lassen, dass am Ende richtig guter Code entsteht. Und das ist doch ein ziemlich gutes Argument dafür, einfach mal ein eigenes Design Pattern zu entwerfen!

Geschrieben von
Ann-Cathrin Klose
Ann-Cathrin Klose
Ann-Cathrin Klose studiert allgemeine Sprachwissenschaft, Geschichte und Philosophie an der Johannes Gutenberg-Universität Mainz. Seit Februar 2015 verstärkt sie als redaktionelle Mitarbeiterin die Redaktion bei Software & Support Media. Zuvor war sie als freie Autorin tätig und hat erste redaktionelle Erfahrungen bei einer Tageszeitung gesammelt.
Kommentare
  1. Chris2017-02-01 18:39:23

    Pattern sind vor allem dazu da die Kommunikation im Team zu verbessern. Damit man bestimmte Konzepte benennen kann und jeder weiß was gemeint ist.

    Eigene Patterns sind daher keine Patterns im herkömmlichen Sinne, sondern einfach Code, der vllt. einen bestimmten Stil hat.
    Eine Art Logbuch ist aber immer sinnvoll, da man sich hier Endscheidungen dokumentieren kann, wenn jemand mal fragt, warum man etwas so oder so gemacht hat.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.