Softwareentwicklung: Patterns bringen klare Vorteile

Eine klar definierte Terminologie, eine verbesserte Dokumentation und das Lernen von den Besten gehört zu den Vorteilen von Entwurfsmustern.

In Pocket speichern vorlesen Druckansicht 109 Kommentare lesen

(Bild: Black Jack/Shutterstock.com)

Lesezeit: 6 Min.
Von
  • Rainer Grimm
Inhaltsverzeichnis

Patterns sind wahrscheinlich die wertvollste und wirkungsvollste Abstraktion in der modernen Softwareentwicklung. Aus meiner Sicht haben sie zahlreiche Vorteile, die ich auf drei Punkte reduziere: eine klar definierte Terminologie, eine bessere Dokumentation und das Lernen von den Besten.

Modernes C++ – Rainer Grimm

Rainer Grimm ist seit vielen Jahren als Softwarearchitekt, Team- und Schulungsleiter tätig. Er schreibt gerne Artikel zu den Programmiersprachen C++, Python und Haskell, spricht aber auch gerne und häufig auf Fachkonferenzen. Auf seinem Blog Modernes C++ beschäftigt er sich intensiv mit seiner Leidenschaft C++.

Meine ersten Vorträge habe ich zwischen 2002 und 2008 über Entwurfsmuster gehalten. In diesem Blogbeitrag schreibe ich über die wichtigen Aspekte, die Patterns aus meiner Sicht auszeichnen.

Meine Argumentation stützt sich auf drei Fakten: eine klar definierte Terminologie, eine verbesserte Dokumentation und das Lernen von den Besten.

Patterns schaffen eine klar definierte Terminologie. So kann ich von einem verwunderlichen Tier erzählen, dass ich beim Joggen gesehen habe. Ich erkläre es in meiner vagen Erinnerung: Das Tier war ungefähr so groß wie eine Katze und hatte Fell und lange Ohren. Seine Hinterbeine waren extrem lang. Deshalb konnte es drei Meter weit und zwei Meter hoch springen. Während es lief, wechselte es dauernd die Richtung. Welches Tier ich gesehen habe? Einen Feldhasen. Den genauen Begriff zu verwenden, hilft sehr. Jetzt haben alle einen Begriff und können ihn ihn auf Wikipedia nachschlagen. Das ist für mich der größte Vorteil von Mustern. Wir haben eine gut definierte Terminologie. Wir wissen, wovon wir sprechen.

Konkreter ausgedrückt: Jemand will einen Newsreader implementieren und bittet mich um meinen Rat. Der Kunde des Newsreader soll automatisch informiert werden, wenn etwas Neues passiert. Meine Antwort kann sehr ausführlich ausfallen und erklären, dass der Newsreader eine An- und Abmeldefunktion haben sollte. Außerdem speichert der Newsreader alle Kunden und jeder Kunde sollte eine Benachrichtigungsfunktion unterstützen. Wenn der Newsreader etwas veröffentlicht, geht er seine Kundenliste durch und benachrichtigt diese. Das ist noch nicht alles. Der Newsreader könnte die Nachrichten verschicken oder nur mitteilen, dass es Neuigkeiten gibt, an denen der Kunde interessiert sein könnte. Ich bin noch nicht fertig mit meinem Rat, aber ich höre hier auf. Im Gegensatz dazu könnte meine Antwort ein Begriff sein: das Beobachtermuster. Die Details dazu finden sich in der Literatur.

Ich möchte zwischen einer feingranularen und einer grob granularen Dokumentation von Software unterscheiden.

  • Feingranulare Dokumentation

Ehrlich gesagt, bin ich kein Fan von feingranularer Quellcodedokumentation wie der folgenden:

// initialize a vector of strings
std::vector<std::string> 
  myStrVec = {"12345", "123456", "1234", 
              "1", "12", "123", "12345"};

// sort the vector of strings based on their length ascending
std::sort(myStrVec.begin(), myStrVec.end(), lessLength);

Im Gegenteil: Code sollte ausdrucksstark sein und sich wie Prosa lesen:

std::vector<std::string> 
  myStrVec = {"12345", "123456", "1234", 
              "1", "12", "123", "12345"};

std::sort(myStrVec.begin(), 
          myStrVec.end(), 
          [](const std::string& f, 
          const std::string& s){return f.length() < s.length();});

Der Code sagt die Wahrheit und ist per Definition immer auf dem neuesten Stand.

In meiner Karriere als Softwareentwickler kam es oft vor, dass ich alte Software pflegen und verbessern sollte. In der Regel war diese Software sehr komplex und es kostete mich eine Menge Gehirnschmalz, sie zu verstehen. Daher war ich sehr froh, dass ich im Quellcode eine Dokumentation fand, die mir half, die Puzzleteile zusammenzusetzen. Leider musste ich später feststellen, dass die Dokumentation veraltet war und ich meine Gehirnleistung in die falsche Richtung investiert hatte. Ich fing wieder bei Null an. Feingranulare Quellcodedokumentation veraltet leicht. Eine veraltete Dokumentation ist sehr schlecht. Code sollte selbsterklärend sein.

  • Grob granulare Dokumentation

Ehrlich gesagt, bin ich ein großer Fan von High-Level-Dokumentation von Software.

Jemand stellt zum Beispiel eine Grafik in UML oder SysML zur Verfügung, die die Architektur der Software beschreibt, und sagt, dass die Software das Reaktor-Muster nutzt. Das Architekturmuster. beschreibt eine bewährte Lösung, um ereignisgesteuerte Anwendungen zu erstellen, die mehrere Clientanfragen gleichzeitig annehmen und an verschiedene Dienstanbieter verteilen können. Jetzt, wo ich das große Ganze verstanden habe, kann ich mehr ins Detail gehen:

  • Die Literatur über das Reaktor-Muster studieren,
  • die Konsequenzen des Musters mit meinen Kollegen diskutieren,
  • die kritischen Komponenten des Reaktor-Musters in der Software identifizieren: Es müssen Komponenten wie ein Reaktor, ein Ereignis-Demultiplexer, Ereignisse und verschiedene Ereignis-Handler Teil der Software sein. Sie haben Namen wie handleEvents, registerHandler, removeHandler, select oder getHandle. Um die verschiedenen Aspekte eines Reaktor-Musters zu implementieren, kommen uns außerdem Design Patterns zu Hilfe. Zum Beispiel sollte der Event-Handler informiert werden, wenn ein spezielles Ereignis eintritt. Ein Beobachtermuster kann hier die richtige Wahl sein. Zudem sollte man dokumentieren, dass man das Beobachtermuster verwendet hat, um diese Anforderung zu lösen. Das ist eine sehr wertvolle Dokumentation auf hohem Niveau.

Muster sind Lernen von den Besten. Gute Lehrmeister sind Kent Beck, James Coplien, Grady Booch oder Eric Gamma, um nur einige zu nennen. Patterns sind "Code-Wiederverwendung" auf einem abstrakten Niveau. Dies ist Code-Wiederverwendung, die am besten funktioniert. Ein Muster beschreibt eine typische Herausforderung in einem bestimmten Kontext und ihre bewährte Lösung. Ein Muster beantwortet auch die folgenden Fragen:

  • Wann sollte man das Muster nicht verwenden?
  • Welche Muster besitzen einen ähnlichen Fokus und können stattdessen in Betracht gezogen werden?
  • Wo wird das Muster verwendet?
  • Welche Varianten des Musters gibt es?

Wie schön wäre es, wenn man neue Software entwirft und nicht in jede Falle tappt.

Die meisten Softwareentwickler gehen davon aus, dass die Begriffe Muster und Entwurfsmuster austauschbar sind. Das ist falsch. Muster ist ein weiter gefasster Begriff und umfasst auch Entwurfsmuster. Mein geschichtlicher Abstecher und die erste Klassifizierung von Mustern im nächsten Beitrag meines Blogs sollten meinen Standpunkt deutlich machen. (rme)