3 ms·

> The point of patterns is to be a body of knowledge about how to make programs. No, the point of patterns is to standardize the language about what everyone

> The point of patterns is to be a body of knowledge about how to make programs. No, the point of patterns is to standardize the language about what everyone already does so programmers can actually discuss what they do with each other in a meaningful way.

gruseom 15y ago
People always say this, but it's not true in practice. Any of these terms that are meaningful can easily be defined in a simple phrase. "Singleton" is an object with only one instance. "Observer" is code that gets called when something changes. (Actually, I think most people who haven't been influenced by GoF say "publish/subscribe" or "handle an event".) Moreover, this is a problem in search of a solution. I don't see programmers having difficulty communicating with each other because of a lack of standard technical vocabulary. If there isn't a term for something, you just make one and say what you mean by it. That's what we've always done and it's what programmers not under the influence of "design patterns" always still do. No, design patterns come with considerably greater baggage than that. They invariably come with template code and a lot of language about when and how to apply the pattern. They're not trying to be a glossary, but a cookbook. Basically, the failed OO mantra of "reuse" took refuge at the meta level where it's impossible to disprove.
- matthewburk 15y ago
  Thank you for this. I agree with everything you have said, but have never been able to say it so well.
- gnaritas 15y ago
  > People always say this, but it's not true in practice. It is true in practice, try talking to programmers who don't know about design patterns and you'll find communication about architecture difficult. Maybe you haven't met enough of these programmers, but there's a shit ton of them in the corporate world. > If there isn't a term for something, you just make one and say what you mean by it. That's what we've always done and it's what programmers not under the influence of "design patterns" always still do. Yes, and it doesn't work well when you don't have a common vocabulary; you spend all your time trying to grok their little custom names for everything. Everything else you said is what happens when people mis-apply patterns and think they're code templates, they're not and were never intended to be.
InclinedPlane 15y ago
This is why I think a book like "Refactoring" is actually more important than the GoF book, because it beats "Design Patterns" at its own game. When someone reads about software design patterns they learn a lot of cool things but ultimately they are still left in a muddle, and as often as not they don't have the slightest clue when and where to use, or not use, which patterns. Worse yet, they can't even use the concepts to talk about real software since so much real software uses undocumented patterns. I think much of this is because "Design Patterns" itself is too raw and too language-centric and too sterile. It's too much of a catalog and not enough advice on why you'd want to use a design pattern and where, and the tradeoffs of doing so. In contrast, "Refactoring" builds up a robust, pragmatic, and practical set of models and terminology for software design and construction, and for making changes to such. It also provides a lot of good rules of thumb and general guidelines for when to know whether a particular refactoring is worthwhile or not. It's very much the level of glue that is missing between the airy almost architecture astronaut level of patterns and the muddy, ugly trenches where real code gets written and re-written. On the whole, someone who's read both "Refactoring" and the GoF patterns book is much more likely to have stepped up their level of coding and increased the sophistication of their models and vocabulary for talking about, reasoning about, designing, and constructing code, whereas someone who has only read about patterns is as likely to be a danger to the codebase as a help.
- gnaritas 15y ago
  Check out "Refactoring to Patterns"; great book shows you both, i.e. how to refactor with a goal pattern in mind to simplify things.

gruseom 15y ago

People always say this, but it's not true in practice. Any of these terms that are meaningful can easily be defined in a simple phrase. "Singleton" is an object with only one instance. "Observer" is code that gets called when something changes. (Actually, I think most people who haven't been influenced by GoF say "publish/subscribe" or "handle an event".) Moreover, this is a problem in search of a solution. I don't see programmers having difficulty communicating with each other because of a lack of standard technical vocabulary. If there isn't a term for something, you just make one and say what you mean by it. That's what we've always done and it's what programmers not under the influence of "design patterns" always still do. No, design patterns come with considerably greater baggage than that. They invariably come with template code and a lot of language about when and how to apply the pattern. They're not trying to be a glossary, but a cookbook. Basically, the failed OO mantra of "reuse" took refuge at the meta level where it's impossible to disprove.

matthewburk 15y ago
Thank you for this. I agree with everything you have said, but have never been able to say it so well.
gnaritas 15y ago
> People always say this, but it's not true in practice. It is true in practice, try talking to programmers who don't know about design patterns and you'll find communication about architecture difficult. Maybe you haven't met enough of these programmers, but there's a shit ton of them in the corporate world. > If there isn't a term for something, you just make one and say what you mean by it. That's what we've always done and it's what programmers not under the influence of "design patterns" always still do. Yes, and it doesn't work well when you don't have a common vocabulary; you spend all your time trying to grok their little custom names for everything. Everything else you said is what happens when people mis-apply patterns and think they're code templates, they're not and were never intended to be.

InclinedPlane 15y ago

This is why I think a book like "Refactoring" is actually more important than the GoF book, because it beats "Design Patterns" at its own game. When someone reads about software design patterns they learn a lot of cool things but ultimately they are still left in a muddle, and as often as not they don't have the slightest clue when and where to use, or not use, which patterns. Worse yet, they can't even use the concepts to talk about real software since so much real software uses undocumented patterns. I think much of this is because "Design Patterns" itself is too raw and too language-centric and too sterile. It's too much of a catalog and not enough advice on why you'd want to use a design pattern and where, and the tradeoffs of doing so. In contrast, "Refactoring" builds up a robust, pragmatic, and practical set of models and terminology for software design and construction, and for making changes to such. It also provides a lot of good rules of thumb and general guidelines for when to know whether a particular refactoring is worthwhile or not. It's very much the level of glue that is missing between the airy almost architecture astronaut level of patterns and the muddy, ugly trenches where real code gets written and re-written. On the whole, someone who's read both "Refactoring" and the GoF patterns book is much more likely to have stepped up their level of coding and increased the sophistication of their models and vocabulary for talking about, reasoning about, designing, and constructing code, whereas someone who has only read about patterns is as likely to be a danger to the codebase as a help.

gnaritas 15y ago
Check out "Refactoring to Patterns"; great book shows you both, i.e. how to refactor with a goal pattern in mind to simplify things.