Entwurfsmuster: Jenseits von Singleton und Observer

[paedubucher]

Ich unterrichte dieses Semester wieder meinen Kurs über agile Softwareentwicklung an der Berufsschule. Ein vorgegebenes Thema dabei sind "Entwurfsmuster". Von der Klasse habe ich vernommen, dass sie z.B. den Singleton schon einmal angeschaut haben; d.h. das kann ich getrost weglassen. (Bzw. könnte ich aufzeigen, warum das eher ein Anti-Pattern ist, womit man bloss globale Variablen dekoriert. Aber das ist ein anderes Thema.)

Nun läuft ein Unterricht zum Thema Entwurfsmuster seit ca. 20 Jahren so ab, dass man zuerst das GoF-Buch zeigt, das man selber nicht durchgelesen hat, und dann z.B. den Observer oder Adapter zeigt; alles schön mit UML-Diagrammen, wobei man noch einmal den Unterschied zwischen der bloss konturierten und der schwarz ausgefüllten Raute auf Wikipedia nachschlagen muss, und dazu das Beispiel bringt: "Ein Auto hat vier Räder; das Rad existiert aber unabhängig vom Auto. Ein Haus hat vier Räume, der Raum existiert aber nur im Kontext eines Hauses. Das ist der Unterschied zwischen Komposition und Aggregation, meine Damen und Herren; das kommt sicher an der Prüfung dran, aber kaum im Berufsleben vor."

Wenn ich aber in den Code reinschaue, mit dem ich es täglich zu tun habe, finde ich darin kaum objektorientierte Entwurfsmuster. Das war auch bei den letzten drei Arbeitgebern so ähnlich.

Muster, die ich sehr oft sehe, sind z.B. filter, map, reduce oder lexikalische Closures. Memoization ist manchmal auch ganz hilfreich, auch wenn ich sowas zugegebenermassen auch recht selten verwende.

Hätte jemand eine Idee, wie man den Begriff der Entwurfsmuster noch etwas weiter fassen könnte? Ich möchte die armen Schüler ja wirklich nicht um das Fassaden-Muster betrügen, aber vielleicht gäbe es da noch wichtigere Muster zu lernen.

[TRex]

Aus dem täglichen Doing: "Composition over Inheritance" ist ein lebendes Dogma, die meisten lösen Auslagern mit letzterem und erzwingen dadurch Strukturen, die nur noch schwer aufzubrechen sind. Man sollte beides kennen und verstehen, warum Entwurfsmuster nicht dazu da sind, seinen Code cooler/professioneller wirken zu lassen, sondern existierende Komplexität zu managen. Wenn da keine ist, dann lässt man es bitte (so ists auch mit dem Singleton).

All das lernt man nicht durch runterbeten des Katalogs.

[paedubucher]

Aus dem täglichen Doing: "Composition over Inheritance" ist ein lebendes Dogma, die meisten lösen Auslagern mit letzterem und erzwingen dadurch Strukturen, die nur noch schwer aufzubrechen sind.

Vererbung zwecks reiner Codewiederverwendung ist wirklich ein Anfängerfehler. Das sollte ich sicherlich erwähnen. Das ist aber eher ein allgemeines Designprinzip als ein konkretes Entwurfsmuster. Das Muster wäre dann, was man sonst machen könnte. Dependency Injection wäre ein wirklich relevantes.

[Meillo]

Man sollte beides kennen und verstehen, warum Entwurfsmuster nicht dazu da sind, seinen Code cooler/professioneller wirken zu lassen, sondern existierende Komplexität zu managen. Wenn da keine ist, dann lässt man es bitte (so ists auch mit dem Singleton).

All das lernt man nicht durch runterbeten des Katalogs.

Da stimme ich zu. Es geht nicht darum, den Katalog auswendig zu lernen, sondern zu verstehen, wann und warum ein Pattern hilfreich ist. Dazu braucht es einen Vergleich und realen/realistischen Code. Also eine Programmieraufgabe, die man einmal ohne Pattern loest und einmal mit und dann die beiden Ansaetze vergleicht. Und dann noch eine zweite Programmieraufgabe, die man wieder auf beide Weisen umsetzt, wo das Pattern die Komplexitaet aber vergroessert.

Besser nur ein einziges Pattern sehr gut lernen als viele schlecht. Wenn man das Prinzip verstanden hat und ein Gefuehl fuer die Bewertung, ob ein Pattern wirklich hilft, gewonnen hat, dann kann man sich weitere Patterns spaeter selber aneignen.

[paedubucher]

Man sollte beides kennen und verstehen, warum Entwurfsmuster nicht dazu da sind, seinen Code cooler/professioneller wirken zu lassen, sondern existierende Komplexität zu managen. Wenn da keine ist, dann lässt man es bitte (so ists auch mit dem Singleton).

All das lernt man nicht durch runterbeten des Katalogs.

Da stimme ich zu. Es geht nicht darum, den Katalog auswendig zu lernen, sondern zu verstehen, wann und warum ein Pattern hilfreich ist. Dazu braucht es einen Vergleich und realen/realistischen Code. Also eine Programmieraufgabe, die man einmal ohne Pattern loest und einmal mit und dann die beiden Ansaetze vergleicht. Und dann noch eine zweite Programmieraufgabe, die man wieder auf beide Weisen umsetzt, wo das Pattern die Komplexitaet aber vergroessert.

Von daher wäre Dependency Injection schon noch interessant, zumal im Kontext mit Unit Tests, das auch Thema des Kurses ist. Ich könnte eine kleine Anwendung zur Verfügung stellen, die Adressen in einer CSV-Datei verwaltet. Für die Persistierung wird ein Objekt verwendet, das den Dateizugriff durchführt. Hier könnte man dann ein Test-Double mitgeben.

Besser nur ein einziges Pattern sehr gut lernen als viele schlecht. Wenn man das Prinzip verstanden hat und ein Gefuehl fuer die Bewertung, ob ein Pattern wirklich hilft, gewonnen hat, dann kann man sich weitere Patterns spaeter selber aneignen.

Eine Gefahr bei Anfängern ist aber auch, dass man mit dem neuen Hammer in der Hand dann überall Nägel sieht. Das ist auch der Grund dafür, warum Singletons selten allein kommen

Das filter/map/reduce-Muster sehe ich da sehr unproblematisch, weil es Abläufe auf eine höhere Abstraktionsebene bringt, die Lesbarkeit aber auch weitgehend steigert.

Nachtrag: zum Thema Klarheit

[schorsch_76]

Bei uns ist viel Objektorientierter Code im Einsatz aber nur eine Hand Voll Design Patterns. Das GoF Buch habe ich mehrfach durchgearbeitet und auch die anderen Design Bücher. Ich denke es ist nicht so wichtig jedes Muster im Detail zu kennen sondern zu wissen was es für bestehende Möglichkeiten gibt Probleme zu lösen. Ein Muster anwenden ohne das es dazu eine Veranlassung gibt macht auch keinen Sinn.

Wir nutzen oft die Strategie: Es ist egal ob es ein Motor des Herstellers A ist oder B, es ändert sich für den Nutzer nichts. Einschalten, Drehzahl, Ausschalten. Das gleiche gilt auch für Sortieralgorithmen: Range an Daten rein, sortiere Daten raus. Es spielt keine Rolle was die Implementierung ist: Quicksort oder Bubblesort (ok ok ok. Laufzeit )
Die Vererbungen sind praktisch nur direkt von der Interface Klasse. Ein Doxygen Lauf zeigt das auch immer sehr schön.

Wichtig und erleuchten fand ich auch die SOLID [1] Prinzipien. Klaus Iglberger hat hier einige schöne Vorträge auf YT.

[1] https://de.wikipedia.org/w/index.php?ti ... edirect=no

[buhtz]

Besser nur ein einziges Pattern sehr gut lernen als viele schlecht. Wenn man das Prinzip verstanden hat und ein Gefuehl fuer die Bewertung, ob ein Pattern wirklich hilft, gewonnen hat, dann kann man sich weitere Patterns spaeter selber aneignen.

Das würde ich auch so unterschreiben.

Vermutlich tendieren die meisten Anfänger dazu, diese Pattern als Regeln zu verstehen. "Das muss so gemacht werden! Und dann sieht es auch cool und professionell aus."

Ich würde Pattern eher als Denkhilfe oder Strukturierungshilfe begreifen. Das Singleton Pattern ist da ein schönes Beispiel, weil man um eine so eigentlich einfach erscheinende Sache, so extrem viel diskutieren und überlegen kann. Es bringt einen dazu, über Dinge und Konsequenzen nachzudenken.
Auch die verwendete Programmiersprache spielt eine Rolle. Ein Observer-Pattern in C++/Java sieht ganz anders aus, als in Python.

Das Erkennen und Zurechtfinden in den Grauzonen sollte der Lerneffekt für die Studieren sein.
Berichte dann doch mal, wie deine Vorlesung ankam.