6 ms·

Most lists of design patterns (including but not limited to the GoF and this site) are written with the noblest of intentions, and contain a lot of insights and

by Jare 13y ago

Most lists of design patterns (including but not limited to the GoF and this site) are written with the noblest of intentions, and contain a lot of insights and interesting solutions. Patterns can provide specific solutions to specific problems, and also a common vocabulary for developers to talk about these problems and solutions. Unfortunately, for the past 18 years I have seen repeatedly (in the game industry and outside) that they tend to be used as shopping lists by developers who can't (or don't have time to) think, design and architect properly. The result of such approach to development, let's call it Pattern Oriented Design, are bloated, overengineered and underperforming systems that are still harder to write, document, test and evolve, than the disorganized messes they replaced. So, nice work, but beware programmers: you must first understand the problem you are trying to solve, before you go shopping for a solution.

epsylon 13y ago
The old adage says "When you hold a hammer, everything looks like a nail." I'd say: learn the patterns, and then forget about them. And when you'll work on an actual problem, the one pattern that is relevant to your problem will come naturally as a solution.
mjn 13y ago
My tentative feel so far on patterns in games is that they're more useful for understanding a design than for constructing one, since as you note pattern-oriented design tends to end up pretty messy. But if you have a design, it can provide a useful vocabulary for talking about what's in it, or how it differs from an alternate design. I'm currently working on a paper trying to analyze the X-Com remake through design patterns, and it seems to be working reasonably well so far. The pattern language gives some hooks for talking about what specifically was kept or changed in the remake. However, for that project we're using more design-oriented rather than programming-oriented patterns, from this project: http://gdp2.tii.se/ http://gdp2.tii.se/ (There used to be a book, but it's out of print: http://www.amazon.com/gp/product/1584503548/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=1584503548&linkCode=as2&tag=kmjn-20 http://www.amazon.com/gp/product/1584503548/ref=as_li_ss_tl?...)
munificent 13y ago
This is one of my concerns too. I've seen patterns be overused almost as much as underused. It's a shame too, because the original Design Patterns book actually goes out of its way to tell you not to use patterns unless they are really a good fit. Unfortunately, remarkably few people have actually read the original book. If you look at the chapter outline, I'm planning to have an introductory section on "How to Use Patterns (and How Not to Abuse Them)" where I'll try to mitigate this. Also, each chapter has a "Keep in Mind" section that focuses on telling you when a pattern might not be a good fit.
- Jare 13y ago
  It's what the book /says/, but in practice it's not what the book /encourages/: a bit like alcohol or sports car TV ads, which all say "drink/drive responsibly". Your own introduction suggests patterns as a cure for bad design and architecture: "I started trying to find books about how to organize programs. Fast-forward several years and a friend hands me a new book: Design Patterns: Elements of Reusable Object-Oriented Software. Finally! The book I’d been looking for since I was a teenager." "But the architecture that this brilliant code hung from was often an afterthought. [...] if they ever cracked open Design Patterns at all, never got past Singleton." I'm sure most cases of badly architected code you have ran into were caused by insufficient time and/or attention devoted to design and architecture. Now the question is, do you think if these coders had the same time/attention but knew patterns, the result would be better? How would it compare to these same coders without patterns but with more time/attention? In that sense, metaphor alert a book of design patterns is to programming what a dictionary is to writing: useful, but mostly orthogonal to the quality of the output.
  - munificent 13y ago
    > I'm sure most cases of badly architected code you have ran into were caused by insufficient time and/or attention devoted to design and architecture. Now the question is, do you think if these coders had the same time/attention but knew patterns, the result would be better? Yes, I do. I've seen a number of times where a smart developer burned hours half-way reinventing from scratch some crude architectural pattern that they could have spent five minutes looking up in a book. Worse, if they had looked it up, they may have learned some of the documented pitfalls that come with it instead of stumbling right into them. I agree there are few things worse than a codebase jam-packed with inappropriate design patterns. Unfortunately, one of the few things that is worse is a code base where the programmers have clearly never learned about any design patterns at all.
philbarr 13y ago
Yes, I would rather that instead of lists of patterns, people would focus on design principles, and just use the patterns as examples of theose principles in practice.
sspiff 13y ago
I agree with you completely. I've encountered a lot of architects and recruiters who seem to put a lot of focus on knowing design patterns, to a point where they seem to forget that you don't always need to employ a well known design pattern. A lot of people seem to think, for instance, that the GoF design patterns are the only design patterns. They just memorize the list, but fail to understand when and why (not) to use them. To me, any frequently employed construction is a design pattern, including but not limited to the classical examples.
- munificent 13y ago
  > To me, any frequently employed construction is a design pattern, including but not limited to the classical examples. The GoF emphatically agrees with you. They considered their book a starting point, not the final word.
tieTYT 13y ago
I've have to make a confession: Almost every time I use a pattern it makes my code more complex and harder to understand. I've used visitor, composite, singleton, all sorts of factories, decorator, proxy, state, strategy, etc. You have a problem, then you realize, "I think this is what the x pattern is for. How does that pattern work, again?" You then google it and try to implement it correctly. Almost by definition, you're not implementing the most obvious solution. If you were, you probably wouldn't have to google it. It'd be better to implement the simplest solution that could possibly work. I think design patterns may be good as a communication tool, and no more. It's faster to say, "factory" than to describe the pattern's implementation. But code maintainability is way higher priority than using a pattern and in my experience pattern implementation and code maintainability are mutually exclusive.
- GuiA 13y ago
  Design patterns are a thing that are useful only when you've essentially rediscovered them for yourself in natural solutions. I developed games as a kid for many years, and I developed solutions to some problems that I identified later as patterns while reading the GoF book. However, if I had read the GoF book in the first place and tried to forcefully implement patterns just based on reading about them in a book, I'd have done a miserable job.
- lifeisstillgood 13y ago
  I actually had to tweet this: Almost by definition, you're not implementing the most obvious solution. If you were, you probably wouldn't have to google it Thank you

by Jare 13y ago

epsylon 13y ago

The old adage says "When you hold a hammer, everything looks like a nail." I'd say: learn the patterns, and then forget about them. And when you'll work on an actual problem, the one pattern that is relevant to your problem will come naturally as a solution.

mjn 13y ago

My tentative feel so far on patterns in games is that they're more useful for understanding a design than for constructing one, since as you note pattern-oriented design tends to end up pretty messy. But if you have a design, it can provide a useful vocabulary for talking about what's in it, or how it differs from an alternate design. I'm currently working on a paper trying to analyze the X-Com remake through design patterns, and it seems to be working reasonably well so far. The pattern language gives some hooks for talking about what specifically was kept or changed in the remake. However, for that project we're using more design-oriented rather than programming-oriented patterns, from this project: http://gdp2.tii.se/ http://gdp2.tii.se/ (There used to be a book, but it's out of print: http://www.amazon.com/gp/product/1584503548/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=1584503548&linkCode=as2&tag=kmjn-20 http://www.amazon.com/gp/product/1584503548/ref=as_li_ss_tl?...)

munificent 13y ago

This is one of my concerns too. I've seen patterns be overused almost as much as underused. It's a shame too, because the original Design Patterns book actually goes out of its way to tell you not to use patterns unless they are really a good fit. Unfortunately, remarkably few people have actually read the original book. If you look at the chapter outline, I'm planning to have an introductory section on "How to Use Patterns (and How Not to Abuse Them)" where I'll try to mitigate this. Also, each chapter has a "Keep in Mind" section that focuses on telling you when a pattern might not be a good fit.

Jare 13y ago
It's what the book /says/, but in practice it's not what the book /encourages/: a bit like alcohol or sports car TV ads, which all say "drink/drive responsibly". Your own introduction suggests patterns as a cure for bad design and architecture: "I started trying to find books about how to organize programs. Fast-forward several years and a friend hands me a new book: Design Patterns: Elements of Reusable Object-Oriented Software. Finally! The book I’d been looking for since I was a teenager." "But the architecture that this brilliant code hung from was often an afterthought. [...] if they ever cracked open Design Patterns at all, never got past Singleton." I'm sure most cases of badly architected code you have ran into were caused by insufficient time and/or attention devoted to design and architecture. Now the question is, do you think if these coders had the same time/attention but knew patterns, the result would be better? How would it compare to these same coders without patterns but with more time/attention? In that sense, metaphor alert a book of design patterns is to programming what a dictionary is to writing: useful, but mostly orthogonal to the quality of the output.
- munificent 13y ago
  > I'm sure most cases of badly architected code you have ran into were caused by insufficient time and/or attention devoted to design and architecture. Now the question is, do you think if these coders had the same time/attention but knew patterns, the result would be better? Yes, I do. I've seen a number of times where a smart developer burned hours half-way reinventing from scratch some crude architectural pattern that they could have spent five minutes looking up in a book. Worse, if they had looked it up, they may have learned some of the documented pitfalls that come with it instead of stumbling right into them. I agree there are few things worse than a codebase jam-packed with inappropriate design patterns. Unfortunately, one of the few things that is worse is a code base where the programmers have clearly never learned about any design patterns at all.

philbarr 13y ago

Yes, I would rather that instead of lists of patterns, people would focus on design principles, and just use the patterns as examples of theose principles in practice.

sspiff 13y ago

I agree with you completely. I've encountered a lot of architects and recruiters who seem to put a lot of focus on knowing design patterns, to a point where they seem to forget that you don't always need to employ a well known design pattern. A lot of people seem to think, for instance, that the GoF design patterns are the only design patterns. They just memorize the list, but fail to understand when and why (not) to use them. To me, any frequently employed construction is a design pattern, including but not limited to the classical examples.

munificent 13y ago
> To me, any frequently employed construction is a design pattern, including but not limited to the classical examples. The GoF emphatically agrees with you. They considered their book a starting point, not the final word.

tieTYT 13y ago

I've have to make a confession: Almost every time I use a pattern it makes my code more complex and harder to understand. I've used visitor, composite, singleton, all sorts of factories, decorator, proxy, state, strategy, etc. You have a problem, then you realize, "I think this is what the x pattern is for. How does that pattern work, again?" You then google it and try to implement it correctly. Almost by definition, you're not implementing the most obvious solution. If you were, you probably wouldn't have to google it. It'd be better to implement the simplest solution that could possibly work. I think design patterns may be good as a communication tool, and no more. It's faster to say, "factory" than to describe the pattern's implementation. But code maintainability is way higher priority than using a pattern and in my experience pattern implementation and code maintainability are mutually exclusive.

GuiA 13y ago
Design patterns are a thing that are useful only when you've essentially rediscovered them for yourself in natural solutions. I developed games as a kid for many years, and I developed solutions to some problems that I identified later as patterns while reading the GoF book. However, if I had read the GoF book in the first place and tried to forcefully implement patterns just based on reading about them in a book, I'd have done a miserable job.
lifeisstillgood 13y ago
I actually had to tweet this: Almost by definition, you're not implementing the most obvious solution. If you were, you probably wouldn't have to google it Thank you