4 ms·

Design Patterns needs to be read with the understanding that the patterns are for specific types of languages and are not universally applicable. Also, it shou

Design Patterns needs to be read with the understanding that the patterns are for specific types of languages and are not universally applicable. Also, it should have a short appendix explaining that you do not get geek brownie points simply by using as many patterns as you can think of. I realize these are not problems with the book per se, and it's worth reading, but some developers seem to get the wrong message from it.

azylman 15y ago
I read Design Patterns and was unimpressed. Maybe it's because I'm used to large codebases that are already well designed, but all I got out of Design Patterns was formal names for patterns that I already used in my code because they're intuitively the correct thing to do.
- deleted 15y ago
  [deleted]
- yvdriess 15y ago
  Indeed, that is the only correct use of Design Patterns.
timr 15y ago
"Design Patterns needs to be read with the understanding that the patterns are for specific types of languages and are not universally applicable." Not really. I've found a use for design patterns in just about every language I've used. They're not all equally useful, but that was never the book's claim. It's become a little fashionable to be cynical about Design Patterns, but most of them have held up well. A few of the patterns were always obscure (even at the time of writing), and a few others are trivially implemented in newer languages, but honestly, there are a lot of people who are doing a poor job of re-implementing the patterns, then doing an worse job of communicating their work. There's something useful about the notion of a consistent engineering vocabulary. Also, I talk to a lot of people who claim to hate Design Patterns, but haven't actually read the book. They've used Java, decided that they hate Singletons and Factories, and thrown the baby out with the bathwater. There's a lot more to the book than just Singletons and Factories.
- nickik 15y ago
  > trivially implemented in newer languages Well this is just wrong! I would call them good languages but that just my opinion. I have never really found it helpful to think about these patterns. Witch one do you find helpful to think about?
  - timr 15y ago
    A lot of them are still useful abstractions (for vocabulary, if nothing else). In particular, I see Strategy patterns used all over the place (but not referred to as such), as well as Adapters, Bridges, Decorators, Facades and Proxies...but most people who have claimed to have read the book couldn't tell you the differences between those ideas. Lots of people seem to independently "re-invent" the Observer and Visitor patterns (badly), which is a shame, because there's lots of room for subtlety in their implementations. And of course, Ruby makes use of Interpreter all over the place, and frameworks like Rails use Command, Chain of Responsibility, Mediator, Template Method, and so on...but don't really call them by their names. Blargh.

azylman 15y ago

I read Design Patterns and was unimpressed. Maybe it's because I'm used to large codebases that are already well designed, but all I got out of Design Patterns was formal names for patterns that I already used in my code because they're intuitively the correct thing to do.

deleted 15y ago
[deleted]
yvdriess 15y ago
Indeed, that is the only correct use of Design Patterns.

timr 15y ago

"Design Patterns needs to be read with the understanding that the patterns are for specific types of languages and are not universally applicable." Not really. I've found a use for design patterns in just about every language I've used. They're not all equally useful, but that was never the book's claim. It's become a little fashionable to be cynical about Design Patterns, but most of them have held up well. A few of the patterns were always obscure (even at the time of writing), and a few others are trivially implemented in newer languages, but honestly, there are a lot of people who are doing a poor job of re-implementing the patterns, then doing an worse job of communicating their work. There's something useful about the notion of a consistent engineering vocabulary. Also, I talk to a lot of people who claim to hate Design Patterns, but haven't actually read the book. They've used Java, decided that they hate Singletons and Factories, and thrown the baby out with the bathwater. There's a lot more to the book than just Singletons and Factories.

nickik 15y ago
> trivially implemented in newer languages Well this is just wrong! I would call them good languages but that just my opinion. I have never really found it helpful to think about these patterns. Witch one do you find helpful to think about?
- timr 15y ago
  A lot of them are still useful abstractions (for vocabulary, if nothing else). In particular, I see Strategy patterns used all over the place (but not referred to as such), as well as Adapters, Bridges, Decorators, Facades and Proxies...but most people who have claimed to have read the book couldn't tell you the differences between those ideas. Lots of people seem to independently "re-invent" the Observer and Visitor patterns (badly), which is a shame, because there's lots of room for subtlety in their implementations. And of course, Ruby makes use of Interpreter all over the place, and frameworks like Rails use Command, Chain of Responsibility, Mediator, Template Method, and so on...but don't really call them by their names. Blargh.