Der PHP Hacker fragt „Haben Pattern versagt?“ und hier ist mein Senf dazu.
Mag jetzt auch mal ein wenig den Stil der „anonymen Programmierer“ haben, aber ich programmiere nicht mit dem Ziel, ein bestimmtes Pattern umzusetzen, sondern mit dem Ziel, ein bestimmtes Problem zu lösen. Dies mache ich auf dem – für mich – besten Wege und der Weg ist für jedes Problem, sogar für jeden Kunden, anders. Meist weiß ich gar nicht, dass ich gerade ein bestimmtes Pattern umsetze oder dass der Weg, wie ich etwas mache, schon einen „XY Pattern“ namen hat.
Schande über mich – ich würde bei dem im Artikel genannten Recruiter wohl keinen Job bekommen – aber meine Fragen wären wirklich:
- Muss man Pattern (auswendig) kennen, um gut programmieren zu können?
Sicher sind Kentnisse über „best practices“ – und aus diesen sind die Pattern ja entstanden – hilfreich, aber muss ich deswegen gleich „in Pattern denken“? Sicher nicht. - Ist es sinnvoll, auf Biegen und Brechen ein Pattern umzusetzen, auch wenn die Problemlösung darunter leidet?
Ganz klar: Nein! Das Pattern sollte sich immer der Problemlösung unterwerfen! Was nützt es mir, dass mein Code in 2.000 Zeilen das XY Pattern sauberst umgesetzt hat, die Problemlösung aber nur 20 Zeilen lang gewesen wäre (und kein Spagetthi-Code ist!). - Muss ich mich nun schämen weil ich das XY Pattern nicht kenne oder bin ich etwa kein guter Programmierer?
Ich denke, es kommt drauf an. Wenn man die „best practices“ versucht umzusetzen und sauberen, lesbaren, skalierbaren und funktionsfähigen Code schreibt, dann muss man nicht unbedingt sagen können, dass dies nun teilweise X, Y und Z Pattern darstellt. Es kommt IMHO drauf an, dass der Code die o.a. Kriterien erfüllt und nicht zwanghaft Punkt 2 umsetzt.
Das wäre mein – wie gesagt – mein Senf dazu. Was denkt ihr darüber?
Meiner Meinung nach lohnt es sich durchaus Designpatterns zu kennen. Designpatterns stellen letzendlich nur Lösungen zu bekannten Problemen. Kennt man die Pattern, erkennt man auch potentielle Probleme besser und kann diese im Vorfeld sauber umgehen. Wer professionell Software entwickelt, der sollte zumindest die gängigen Pattern kennen. Der Einsatz bleibt jedem selbst überlassen und natürlich macht es keinen Sinn Pattern zu verwenden, wo sie nicht passen.
Ansonsten lohnt sich auch ein Blick auf die Anti-Pattern. Ein „So auf keinen Fall“ ist nämlich auch ganz lehrreich.
Nicht nur beim Probleme erkennen und sauberen entwickeln machen Design Pattern Sinn, auch generell beim Austausch mit anderen Entwicklern. Es ist oftmals einfacher/schneller/effizienter nur das Design Pattern zu nennen, anstatt es stundenlang umschreiben zu müssen. Setzt natürlich voraus, dass man die Design Pattern benennen kann.
Aber die Programmierfähigkeit davon abhängig zu machen, wie viele Pattern man kennt, halte ich für absoluten Schwachsinn.