Kategorien
Benutzt keine Entwurfsmuster
Da heute der internationale Tage der Provokation wäre, falls es diesen geben würde, fange ich doch einfach mal mit einer solchen an. Die meisten von euch denken jetzt wahrscheinlich, dass der Langner wohl ganz fies auf den Kopf gefallen ist und deswegen solche Aussagen trifft.
Ich stehe natürlich nicht wirklich hinter dem Thema, denn ich bin ein großer Fan dieser Lösungen. Mein Problem damit ist eher anderer Natur. Viele Entwickler, die ich im Laufe der Jahre kennengelernt habe, verwenden Entwurfsmuster, weil sie es können. Da habe ich schon öfters das Gefühl, dass die Entwickler mit ihrem Code nicht zufrieden sind, falls sie es nicht geschafft haben mindestens ein Design Pattern unterzubringen. Und leider sieht der Quellcode dann auch so aus. Irgendwie hat man den Eindruck, dass die Muster da brutal reingedrückt wurden, obwohl sie gar nicht passen. So puzzle ich übrigens, wenn ich nicht weiter kann.
Aber warum passiert so was eigentlich? Entwurfsmuster sind professionell, da sind wir uns sicherlich einig. Wir alle wollen auch professionell sein. Das ist wohl auch Fakt. Tja 1+1 zusammenzählen. Wir benutzen Patterns, um professionell zu sein. Leider wirken wir so nur professionell und sind es nicht, denn meistens habe ich das Muster gar nicht verstanden, wenn ich es nicht richtig einsetzen kann.
Wie kommt man aber um das Problem rum? Entwurfsmuster sind eine wunderbare Erfindung in der Softwaretechnik. Danke an die Gang of Four dafür. Wir müssen einfach in privaten Projekten anfangen zu lernen. Dort ist es echt egal, falls man was in die Hose geht. Da ist es sogar gut, denn man verliert nichts, wenn es mal schief geht und lernt eine Menge. Und es wird schief gehen, zumindest war das bei mir so. Die Muster die ich dann im Beruf einsetze muss ich beherrschen und das schaffe ich nur mit Erfahrung. Denn die meisten Patterns klingen einfacher, als sie nun mal sind.
Das Problem besteht tatsächlich und kommt meist von einer gewissen Unwissenheit. Die ist aber nur durch neue Erfahrungen zu ändern. Ein einfacher wie effizienter Weg wären hier Peer Reviews, da man so immer noch eine zweite Meinung bekommt. Zwar kann man so nicht besser werden, als alle Beteiligten in der Summe, aber immer besser als man alleine wäre.
Als ich vor 8 Jahren mein Studium absolvierte nahmen wir auch alle gängigen Patterns durch. Ich konnte mit der ganzen Thematik nicht wirklich viel anfangen, weil ich noch nicht bereit war und erkannte wie wichtig diese Patterns sind.
Aktuell lese ich gerade PHP Design Patterns von Stephan Schmidt und bin ein richtig kleiner Fan geworden.
Ich tue mich aber sehr schwer mit dem Einsatz. Erstens weiss ich häufig nicht mal, was das Pattern genau macht, wenn ich den Namen höre. Zweitens bin ich unsicher, ob das eingesetzte Pattern für meine Problemstellung überhaupt das richtige ist.
Gibt’s hierfür gute Tips ausser üben in privaten Projekten?
Also Christians Ansatz geht auf jeden Fall in die richtige Richtung. Per Reviews sollten aber vorher auf architektureller Ebene geschehen, ansonsten kann man nur noch den Schaden limitieren und nicht verhindern. Was aber ganz sicher funktionieren sollte, ist Pair Programming. Jemand der mit Mustern umgehen kann und ein Newbie an einem Tisch sollte genau das richtige sein.
Ja, aber genau dort wo man es am Anfang macht (Privat, Hobbyprojekt, einfach mal sinnlos üben usw) gibt es niemanden, der sich das anschaun kann. Da fällt dann Peer Reviews ins Wasser.
Und wenn man es dann irgendwo im Netz postet, kommt meißt die Antwort, dass niemand unentgeldlich den Code durchgeht(Geht zumindest mir so).
Und nur durch lesen & fremden Code „analysieren“ wird man nicht immer schlauer:(
@ragtek: Richtig, das Lesen von fremdem Code als Lerngrundlage halte ich für kritisch. Gerade Einsteiger können mangels Erfahrung guten von schlechtem Code nicht wirklich unterscheiden. Und wenn sie dann beginnen, schlechten Code fürs Lernen zu benutzen, kann da nichts wirklich gutes dabei herauskommen.
Zum Thema Patterns: Es gibt die Kaste der IT-Architekten, die gern mit Buzzwords um sich werfen, wobei Patterns (und Anti-Patterns) da einen großen Anteil einnehmen. Theoretisch erklären können die dann auch alles so in etwa, wenn es aber dann darum geht, diese Patterns in Code zum Leben zu erwecken, sieht es meist ganz düster aus. Ich kenne einige Entwickler, die wissen gar nicht, was eine Factory ist, setzen dieses Pattern aber intuitiv ein, weil sie merken, dass es elegant und logisch ist. Das ist doch eigentlich der bessere Ansatz, oder?
Ich muß Marek recht geben, es gibt einige Entwickler, die setzen Pattern ein, und wissen noch nicht mal, das es welche sind. Dependency Injection ist ein gutes Beispiel für so was, oder halt auch die Factory. Ich denke auch, das vieles von einiges Leuten überstrapaziert wird. Mir persönlich ist es zum Beispiel egal wie z.B. ein Entwurfsmuster oder meinetwegen auch ein Allgorithmus heißt, Hauptsache er funktioniert so wie ich es erwarte.
Sehn wir es doch einmal ganz objektiv:
Die meisten Tutorials beschreiben die Patterns als Generallösung. Ich selbst habe dies besonders beim Singleton erlebt, das klang dann ungefähr so: „Von manchen Klassen möchte man generell im gleichen Klassenraum bleiben, zum Beispiel bei der Datenbankverbindung bzw. ihrer Klasse“.
ZACK: Alle benutzen das Singleton. Jetzt gerade wird die Dependency Injection als testbare Singleton-Alternative angepriesen, ihr wisst wohl was jetzt kommt…
Ich stimme in dem Zusammenhang voll und ganz zu. Die Design Patterns stellen eine Lösung für generelle Problemfälle in der Objektorientierten Programmierung dar, und sagen einem nicht wie man seine Klassen zu entwerfen hat.
Mein Standpunkt: Hier werden die Tutorials meist entweder von Leuten, die genau diesen Punkt nicht verstanden haben, verfasst, oder es wird nicht explizit darauf hingewiesen, dass sie keine Programmiervorschriften darstellen.
@Mario
Die Vorteile der Namensgebung von Design Patterns liegen in der Kommunikation. Mit eindeutigen Ausdrücken kann man viel besser kommunizieren. Das haben ja auch die GoF in ihrem Buch so geschrieben. Wenn jeder eine Factory anders nennt, wird es schwer sich dazu zu bilden (sei es per Internet oder Fach-Literatur).
Für mich stellt Software-Architektur auch immer einen iterativen Prozess dar. Man programmiert etwas und muss ständig prüfen ung ggf. verbessern ob es noch den Ansprüchen genügt. Over-Engineering ist zwar für den Entwickler ganz cool, aber für den Kunden / Arbeitgeber bringt das keinen Cent mehr Ertrag.
@Ulf
Das stimme ich dir auch zu. Was ich sagen wollte, ist lediglich, daß viele Entwickler diese Pattern schon verwenden und keinen Schimmer hatten, wie sie heißen. Geschweige denn, das es schon schicke Definitionen dafür gibt oder gab. Natürlich ist es nützlich für die Kommunikation, wenn ich von Birnen rede sage ich ja auch nicht Äpfel 😉 Aber für die eigentliche Programmierarbeit spielt es keine Rolle. Der Ansatz ist auch bei vielen Leuten unterschiedlich, die einen tuns und finden dann in der Theorie die Bestätigung, und die anderen nehmen die Theorie und wenden es dann in der Praxis an. Ich glaube nirgends in der Programmierung ist dies zutreffender, als bei der Verwendung von Pattern und dergleichen.
@Marek: Das Lernen von anderen, durch Abgucken, finde ich ansich sehr gut. So habe ich z.B. HTML, CSS und auch PHP gelernt. Funktioniert ja auch im realen Leben, dass wir uns als Kinder alles abgucken und es nachmachen. Dass wir dabei auch mal auf die Nase fallen ist normal. Du kannst auch in deiner Kindheit bei den falschen Personen lernen. So ist das beim Abgucken von Code auch. Das eigentliche Problem ist nicht das Abgucken, sondern, dass man dann meist vergisst den Code später auch zu verstehen. Da kommt die Frage „Warum soll ich den Code verstehen? Er tut doch das, was ist will.“.
—
Die meisten Tutorials beschreiben die Patterns als Generallösung.
—
Seh ich genauso – leider. Die meisten Ansätze die man im Internet findet hauen den eigentlichen Inhalt des jeweiligen Musters komplett gegen die Wand. Es ist doch keine Pflicht Design-Patterns zu verwenden. Wenn sie passen – dann nimmt man sie her – wenn nicht – dann eben nicht.
Das ganze kann man schön umgehen indem man das Projekt wirklich von Anfang an genau durchplant.
Früher habe ich frei Schnauze programmiert. Dann mit den hiesigen Frameworks MVC kennen gelernt und dann über Stephan Schmidt’s PHPDesignPatterns (großartiges Buch) über Head First Design Patterns zu DDD und PoEAA gefunden.
Ich behaupte einfach mal, ich habe die Patterns, die ich nutze auch weitgehend verstanden. Nicht von der Hand zu weisen ist allerdings auch, dass eine Anwendung zu erstellen seitdem wesentlich länger braucht und hinterher nicht unbedingt leichter zu warten wären, als ohne Patterns. Das Problem ist weniger, ein einzelnes Pattern anzuwenden oder zu implementieren, als vielmehr Patterns im Kontext zu kombinieren, eben Engineering zu betreiben, statt „nur“ Programming.
Zitat von Marc Binder: „Das ganze kann man schön umgehen indem man das Projekt wirklich von Anfang an genau durchplant.“
Du hast da einen sehr wichtigen Begriff in die Runde geschmissen: Planung!
Ohne Planung, bzw. ohne sich mal Gedanken darüber zu machen, was man überhaupt für ein Problem hat und wie man es letztendlich lösen möchte, kommt man schnell dazu, dass Patterns wie wild verwendet werden, obwohl man sie eigentlich garnicht braucht oder viel besser ein anderes Pattern hätte nutzen sollen/müssen. Änderungen am bestehenden Code, bei dem man merkt, dass das benutzte Pattern doch nicht passt, sind umständlich und kosten sehr viel Zeit.
Daher immer daran denken, so klein das Problem und die Lösung zu sein scheinen, immer mal darüber nachdenken, bevor man am Ende umständlich alles abändern muss.
Vielleicht kann es auch sein, dass Patterns zu schnell für irgendwelche Problemlösungen verwendet werden, da sie in Büchern und/oder Tutorials an zu einfachen Beispielen vorgestellt werden. Zwar ist es ansich der Sinn von Tutorials etc. Problemlösungen an einfachen Beispielen zu verwenden, aber man versteht dabei nicht unbedingt, wie mächtig diese Patterns sein können, wenn man sie mit Verstand umsetzt und verwendet.
Seh ich genauso. Allerdings ist es eher gang und gebe, dass man eben nicht plant.
Ich würde nicht sagen dass es schlecht ist sich fremden Code anzusehen, irgend woher muss man sich ja auch mal etwas ab gucken und lernen wie die Profis arbeiten.
In einigen Fachbüchern (besonders die für Einsteiger) werden Design Patterns und Planung eines Projekts überhaupt nicht bzw. nur teilweise genannt. Da muss man erst mal darauf kommen dass es so etwas überhaupt gibt^^
Grundsätzlich ablehnen würde ich Pattern auch nicht, ich würde sie in der Planung berücksichtigen und mir genau überlegen wann ich welches brauche und ob es wirklich unbedingt notwendig ist oder es Alternativen gibt. Durch zu viele Pattern kann ein Code sehr schnell sehr unübersichtlich werden und vor allem für einen Anfänger, aber auch für einige fortgeschrittene, zu komplex für Änderungen werden.
Des weiteren sollte man nicht vergessen das Design Pattern schließlich auch nur Entwurfsmuster und keine allgemeinen Richtlinien oder ein allgemeiner Muss sind!
P.s. das schon genannte Buch PHP Design Patterns von Stephan Schmidt kann ich jedem der Design Patterns lernen will nur empfehlen (Für Anfänger ist es aber glaube ich zu komplex).
In einigen Fachbüchern (besonders die für Einsteiger) werden Design Patterns und Planung eines Projekts überhaupt nicht bzw. nur teilweise genannt. Da muss man erst mal darauf kommen dass es so etwas überhaupt gibt^^
——-
Und da ist das Problem: Wenn keiner das wichtigste Thema anspricht, dass es in der Entwicklung gibt, achtet gar keiner mehr drauf.
Oft wird bei PHP von Pattern gesprochen und damit dann solche gemeint, die für Sprachen, die in binärform statisch gelinkt werden entworfen wurden.
Ich denke eine Lektion ist es da zu verstehen, warum bestimmte Dinge damals aufgeschrieben wurden und warum die gerade für eine interpretersprache wie PHP nicht unbedingt Sinn machen.
Ausserdem gibt es auch aus der näheren Zeit um die Veröffentlichung des Buches der „Gang“ eine kritische Auseinandersetzung mit dem Titel.
Objektorientierung ist halt auch nicht der heilige Gral.