I came into professional software development just as patterns were emerging as the "next big thing".
It seems to me looking back that at best we would have to rate the success of design patterns as mixed. One the one hand they've formed a useful vocabulary for discussing software designs and a useful tool for thinking about software in general. However on the other hand it seems like in a huge number of cases they have inspired large amounts of complexity and over-engineering and get misused more often th
Your final sentence is a funny question, or an interesting question, so you deserve be modded up.
However: why should one not use Design Patterns anymore. You saw overengineered software? So likely the software suffered from some anti patterns? So you stop using Design Patterns? I can't believe that, this makes no sense. With what and why would you replace a model/view/controller pattern, or why a factory?
Many old school programmers demand youngsters learn C... with the same demanding voice I want that old
You're right, I probably could have phrased the last question better.
When I say "use design patterns", what I really mean is put them front and center in the design process, using them as building blocks when designing software. This was definitely the vision people had at one point. My experience however has been that they are rarely successful when used that way. I'd say everyone does in fact use design patterns by definition - design patterns are after all just descriptions of common designs, so you'd have to be going out of your way and doing very unusual things to avoid them. But my experience is that in successful designs the patterns tend to emerge *after* you've built the software and become useful as way to discuss it and communicate about it, and possibly to critique it, but not really to build it in the first place. Somehow, conceptualizing designs as made out of pattern building blocks always seems to lead to over-engineering. My theory is that, with software, anything that distracts from the principle of "the simplest thing that could possibly work" ends up being a negative. We are enchanted by the idea of software being like buildings - let's put an arch over there, a staircase here, split level room here... in architecture that makes buildings beautiful, but in software it just makes it unnecessarily complex.
So - hopefully that clarifies what I mean. I'm curious if this is also his experience, or not.
Please re-read the book. I wish I had it here (my copy is about 5000 miles away at the moment), but I think what you just wrote is already there. A design pattern, by definition, is something that is intuitively used by many people, whether they know what it's called or not. IIRC you can't call it a pattern unless there are 3 independent implementations of it. So one of the biggest pluses for design patterns is in being able to recognize them in existing code and thereby understand it more easily.
The ne
"Spock, did you see the looks on their faces?"
"Yes, Captain, a sort of vacant contentment."
What do you make of Patterns now? (Score:4, Interesting)
I came into professional software development just as patterns were emerging as the "next big thing".
It seems to me looking back that at best we would have to rate the success of design patterns as mixed. One the one hand they've formed a useful vocabulary for discussing software designs and a useful tool for thinking about software in general. However on the other hand it seems like in a huge number of cases they have inspired large amounts of complexity and over-engineering and get misused more often th
Re: (Score:2)
Your final sentence is a funny question, or an interesting question, so you deserve be modded up.
However: why should one not use Design Patterns anymore. You saw overengineered software? So likely the software suffered from some anti patterns? So you stop using Design Patterns? I can't believe that, this makes no sense. With what and why would you replace a model/view/controller pattern, or why a factory?
Many old school programmers demand youngsters learn C ... with the same demanding voice I want that old
Re:What do you make of Patterns now? (Score:4, Interesting)
You're right, I probably could have phrased the last question better.
When I say "use design patterns", what I really mean is put them front and center in the design process, using them as building blocks when designing software. This was definitely the vision people had at one point. My experience however has been that they are rarely successful when used that way. I'd say everyone does in fact use design patterns by definition - design patterns are after all just descriptions of common designs, so you'd have to be going out of your way and doing very unusual things to avoid them. But my experience is that in successful designs the patterns tend to emerge *after* you've built the software and become useful as way to discuss it and communicate about it, and possibly to critique it, but not really to build it in the first place. Somehow, conceptualizing designs as made out of pattern building blocks always seems to lead to over-engineering. My theory is that, with software, anything that distracts from the principle of "the simplest thing that could possibly work" ends up being a negative. We are enchanted by the idea of software being like buildings - let's put an arch over there, a staircase here, split level room here ... in architecture that makes buildings beautiful, but in software it just makes it unnecessarily complex.
So - hopefully that clarifies what I mean. I'm curious if this is also his experience, or not.
Re: (Score:3, Interesting)
Please re-read the book. I wish I had it here (my copy is about 5000 miles away at the moment), but I think what you just wrote is already there. A design pattern, by definition, is something that is intuitively used by many people, whether they know what it's called or not. IIRC you can't call it a pattern unless there are 3 independent implementations of it. So one of the biggest pluses for design patterns is in being able to recognize them in existing code and thereby understand it more easily.
The ne