Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
99% of the time design patterns are nothing more than common practices already used
I'd say 40%, tops. Part of the thing with patterns is that they present fomalised solutions. I've yet to meet someone who's read a Patterns book, stepped back, and went nuts about how they were now realising all those complex numerous classes in Project X could have been significantly simplified using Pattern Y.
The great thing about Patterns is giving you a set of simple concepts in designing code. Without them you do end up struggling because it's difficult to conceptualise what you're trying to achieve. I know for a fact I became a much better developer after reading POEAA and GOF. While some of them do look familiar, you usually get to them completely by accident with maybe 300% extra code .
- 1/3 of patterns just give names to common solutions that most programmer know naturally,
- a second 1/3 are solutions that seem obvious after you learn them, but you would probably not arrive at them naturally.
- the final 1/3 are solutions that so brilliantly counter-intuitive that you never really fully understand the depths of them, but more is revealed each time you implement them.
Sort of like the algebra, geometry and calculus levels of patterns.
Admittedly 99% was a optmistic estimate. However wouldn't that number be based more on personal experience than anything?
I honestly haven't had an "aha" moment with any patterns except architectural MVC model 2 especially. My vocabularly currently consists of around 35 patterns and with MVC (front & page controller) being the only one that left me in the dark for a bit, that would indeed yield a number much closer to 85-90% and not 30%.
Obviously some patterns leave me scratching my head seeking a second opinion (I still have to question MVC sometimes as I occasionally see issues arise which are not mentioned in articles/books, etc) but it usually takes a quick read and immediately I've located a portion of my source code which I can further study and develop a firm understanding of the problem/solution. When I have formalized my understanding of the pattern, it usually simplifies things, both in describing the code and in my own understanding but 9/10 times I've already solved the problem as the pattern dictates it just hasn't been labeled or identified as "so and so" pattern.
I wager 5 of your 9 times were overly complex compared to the same effort after reading about the relevant pattern . Like arborint pointed out, once you read a pattern it often looks stupidly obvious - but once it's obvious that just means you'll do it far simpler next time because you've gained a fuller understanding of the problem being solved.
Maugrim_The_Reaper wrote:I wager 5 of your 9 times were overly complex compared to the same effort after reading about the relevant pattern . Like arborint pointed out, once you read a pattern it often looks stupidly obvious - but once it's obvious that just means you'll do it far simpler next time because you've gained a fuller understanding of the problem being solved.
Did you know that: Over 85% of wagers fail or prove to be false. Did you also know that 99% of statistics are made up on the spot?
There is no dought in my mind that learning about design patterns will make anyone a better developer. What I was suggesting I guess, is that each developer will improve more or less than the next depending on the current skillset and experience at the point which they began learning about design principles.