// der php hacker

// archiv

Haben Design Pattern versagt?

Geschrieben am 10. Nov 2010 von Cem Derin

Beim morgentlichen stöbern durch die Entwickler-Blog-Welt bin ich auf einen Artikel aus Australien gestoßen, in dem die gewagte These aufgestellt wird: Design Patterns haben versagt. Es wird mit der Einleitung begonnen, dass man selbst so viele Design Pattern wie möglich benennen und erklären soll. Und zwar, bevor man weiterliest. Ein wenig Brimborium, Design Pattern sind ganz nett, aber schlussendlich gibt es ein Problem:

“Design patterns have flopped because most programmers don’t know design patterns well enough to recognise the recurring problems that they solve.”

zu Deutsch: Design Patterns haben versagt, weil die meisten Programmierer sie nicht gut genug kennen um zu verstehen, welche Probleme sie lösen.”

Vor allem in Verbindung mit dem ersten Absatz impliziert diese Aussage, dass man alle Design Pattern auswendig kennen muss, um sie richtig verwenden zu können. Das wird auch noch einmal damit unterstrichen, dass der Autor ganz offensichtlich aus dem Recruiting-Umfeld stammt, und Bewerber regelmäßig Pattern aufsagen oder erklären lässt. Zumindest ersteres wäre auch für mich ein Problem: Ich merke mir Sachen, die ich mir merken muss. Ich muss mir Sachen merken, wenn ich sie täglich Anwende. Ein Pattern wende ich aber nicht an, sondern ich setze das Resultat ein – es sei denn, ich entwickle etwas auf Grundlage von Pattern. Die allermeisten könnte ich aber aus dem Stehgreif erklären.

Ich sehe hier also keine Ambivalenz zwischen der mangelnden Fähigkeit rund 30 Pattern auswendig aufsagen zu können und der Tatsache, dass ich das Konzept dahinter nicht verstehe. Um zur Frage im Titel zurückzukommen: Nein! :)

Geschrieben in Entwicklung, Theorie 8 Kommentare

#001
10. Nov 2010

Ich wiederspreche dir jetzt einfach mal und sage: Ja, sie haben versagt.

Denn die Existenz von Design Patterns sollen das Programmieren nicht nur erleichtern und beschleunigen, sie sollten sowas wie Best Practice für bestimmte Problemfelder darstellen um auch die allgemeine Code Qualität zu verbessern.

Das wohl am meisten bewusst verwendete Pattern scheint das Singleton zu sein.
Das ist auch ein gutes Beispiel um zu zeigen, dass sie doch versagt haben.
Es soll ja dazu dienen, das Klassen bei denen mehr als eine Instanz Probleme bereiten, eben nur noch maximal eine Instanz erhalten.
Wofür wird es aber hauptsächlich eingesetzt?
Es wird mit der Absicht genutzt, Objekte erst bei der ersten wirklichen Nutzung zu Initialisieren. Da man dadurch nicht mehr dem Prinziep der Dependency Injection folgt, schafft man sich eine ganze Reihe von statischen Abhänigkeiten, welche eher als qualitativ schlecht zu beschreiben sind.

Daher vertrete ich den Standpunkt, dass Design Patterns die allgemeine Code Qualität eher verschlechtert haben.


#002
10. Nov 2010
Cem Derin

Ah, die gute, alte Singleton-Diskussion. Prinzipiell hast du recht. Kannst du denn ein weiteres Beispiel nennen? Oder anders: Kannst du den Großteil aller Patterns als “nichtig” herauslösen? Ich verstehe nicht so ganz, wie man ein Konzept als “falsch” darstellen kann, nur weil einige (oder meinetwegen auch viele) Leute nicht verstehen, wie es funktioniert und es sogar falsch Einsetzen.

Meiner Meinung nach ist ein “falsch” oder “schlecht” eingesetztes Pattern besser als gar keins oder selbst ausgedachtes krudes Zeug. Auch wenn die Qualität dann nicht gut ist – ohne wäre sie vermutlich noch schlechter.


#003
10. Nov 2010
Entwurfsmuster

Man kann noch so viel auswendiglernen, ohne auch nur irgend etwas verstanden zu haben (das ist leider insbesondere im wirtschaftlichen Umfeld sehr verbreitet und erklärt zugleich viele Probleme der Gesellschaft).

Da ist es doch weitaus besser, man denkt erst einmal selbst über das eigentliche Problem nach. Den “etablierten” Begriff dazu finden und Detail-Verbesserungen vornehmen kann man dann immer noch. Entwurfsmuster sind keine Fertiglösung für alle Probleme, sondern eine – sicherlich gute – Orientierungshilfe.


#004
10. Nov 2010

Nagut, ich gebe zu, dass ich nicht sonderlich viele Patterns kenne. Dazu müsste man vermutlich auch wissen, was alles als Pattern zu bezeichnen ist.
Ich vermute, dass vor allem in letzter Zeit (mir) bekannt gewordene Konstrukte, schon gar nicht mehr als Pattern bezeichnet werden.

Nehm ich also mal die 3 Pattern, welche im Zusammenhang mit Design Pattern immer wieder fallen.

Singleton habe ich ja schon beschrieben.

Dann gibt es das Registry Pattern. Im Grunde sieht das für mich nur nach einem Globalem Array aus, dass seinen eigenen Namespace zugewiesen bekommen hat.
Ein $_GLOBALES['namespace'] hätte den selben Nutzen und zeigt wesentlich besser, womit man es da eigentlich zu tun hat.

Und schließlich der Dritte im Bunde, das Factory Pattern.
Hiermit soll das Problem gelöst werden, dass die verwendete Klasse erst zur Laufzeit bekannt ist. Lösbar wäre das je nach Fall, mit einer switch Anweisungen und den verschiedenen Möglichkeiten oder durch ein “new $classname”.
Das Factory Pattern macht im Grunde das selbe, nur dass es diesen Vorgang in eine eigene Klasse auslagert.
Ich gebe zu, das kann sogar Sinnvoll sein, wenn das erzeugen der nötigen Objekte eine komplexere Aufgabe ist, und der selbe Code auch noch von mehreren Klassen verwendet wird.
Nun aber zur Schwäche der Factory. Wenn man Unittests schreibt, ist es bei komplexeren Anwendungen von Vorteil Mockobjekte zu verwenden. Also Objekte, welche das Verhalten nur Simulieren ohne zum Beispiel wirklich eine Datenbankverbindung aufzubauen oder 100 Mails an eine Maillist zu versenden.
Wenn die Klassen jedoch statisch von dieser Factory Abhänig sind, bekommt man Probleme. Man könnte sie zwar trotzdem noch durch eine “Mock” Factory austauschen, indem man beim includen der Klassen ansetzt, aber bei einer größeren Zahl von Factorys wird das mit sicherheit nicht mehr so übersichtlich.

So, das waren alle Pattern, die mir regelmäßig über den Weg laufen.
Der Fairnis halber habe ich aber selbst auch nochmal ein wenig nach weiteren Pattern gesucht und bin sogar fündig geworden.

Da wäre das Null Objekt Pattern, interessanterweise scheint das deckungsgleich mit dem zu sein, was inzwischen als Mockobjekt bezeichnet wird. Und ja, das würde ich als ein Sinnvolles Pattern bezeichnen.
(das habe ich namentlich übrigens genauso wie die nächsten von http://www.phpbar.de/w/Entwurfsmuster )
Lustigerweise findet sich dort auch Iterator unter den Patterns. Lustig deshalb, weil es so gar nicht mit meiner vorherigen Beschreibung zusammen passt, was ein Design Pattern eigentlich ist.
Das Composite Pattern sieht auch ganz in Ordnung aus. Erfüllt alles was man von einem Design Pattern erwarten würde. Und praktischerweise ist auch genau das zu lösende Problem mit beschrieben. Vermutlich ist es einfach zu speziell, damit jemand auf die Idee zu kommt, es falsch einzusetzen.

Da sind zwar noch zwei weitere Pattern beschrieben, aber nu hab ich erst mal genug.
In dem Zusammenhang interessiert mich nur, ob man Dependency Injection oder was nun neu in der PHP Welt ist, Dependency Injection Container auch als Design Pattern bezeichnen würde. Denn gerade diese beiden Dinge finde ich, sind es Lohnenswert weiter verbreitet zu werden.


#006
11. Nov 2010

Wäre MVC nicht auch ein Pattern?
Denn dies halte ich durchaus für sehr sinnvoll.


#007
12. Nov 2010
RennerChristian

Das schreiberische Engagement von flyingmaniac in allen Ehren, aber letztendlich belegt es nur die Richtigkeit der – wenn auch trivialen – Kernaussage, des Originalzitats.

Der flächendeckende Einsatz von Design-Patterns scheitert an der Unfähigkeit oder des Unwillens der Entwicklergemeinde sich mit deren Theorie auseinanderzusetzen. In meinen Augen ein Armutszeugnis.

#008
07. Mai 2011

[...] PHP Hacker fragt “Haben Pattern versagt?” und hier ist mein Senf [...]

// kommentieren

// senden
theme von mir, software von wordpress, grid von 960 grid system. funktioniert in allen browsern, aber der safari bekommt das mit der schrift am schönsten hin.