4 ms·

The problem with the design patterns books (including the GoF one) is that in the end they didn't have much influence. Think of how few of their patterns have b

The problem with the design patterns books (including the GoF one) is that in the end they didn't have much influence. Think of how few of their patterns have become part of the vernacular of our field: Iterator, Singleton, Factory, Adapter, and maybe one or two more. It's not a long list. If you insist on talking in terms of design patterns, you are going to have to explain nearly all of them to your listeners. Insofar as the authors' goal was to create a shared language of patterns we could use for clearer communication of designs, they fell well short.

shagie 10y ago
Having seen far too many questions on sites about software design where someone starts out with "How do I use a Factory to solve...", I would contend that the GoF had far too much influence and missed the designer's original goals. > Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution. From an interview with Erich Gamma ( http://www.artima.com/lejava/articles/gammadp.html http://www.artima.com/lejava/articles/gammadp.html )
- nickpsecurity 10y ago
  Im leaning in that direction. Beginners did much better with methods like Cleanroom since it was all straight-forward decomposition of modules into easy-to-verify functions and acceptance tests. Amateurs trying to apply patterns often plaster them everywhere in designs that sometimes make structured programming in BASIC look more readable.
blub 10y ago
Some patterns have become parts of languages and libraries as those evolved. Subject-observer lives on in Qt's signals and slots and in general any signal/slot library. Command is basically operator() or std::function in C++. Null object is a useful little trick. I'd also add Facade and Strategy to your list. It's indeed not long but it does save some time when talking about design and various potential solutions. That's good enough for me. P.S: I think head first patterns should be preferred to the GoF book if one insists on learning from a book, but otherwise they can be grasped from a Wikipedia article.
- leksak 10y ago
  I think Game Programming Patterns is an excellent read for learning patterns
InclinedPlane 10y ago
The GoF design patterns book has two core, very closely related, problems. The first is that it doesn't make enough of an effort to present "design patterns" as a conceptual framework. Can you program without using design patterns? No, you cannot. You are always using design patterns whether you know it or not, you're just using ad hoc design patterns without realizing it when you don't think you're using patterns. The book's failure to elucidate commonly used ad hoc patterns as well as common anti-patterns is one of its principle shortcomings. This is something that the refactoring book did much better, by providing examples of how things can be engineered in different ways and why one way might be desirable over another (and how to transition between them). Instead the GoF book largely presents a canonical list of some design patterns, giving people the false impression that these are special and unique versus merely a sampling of ways one might do things. Additionally, the GoF book doesn't make it clear that each design pattern exists to work around specific constraints, and thus doesn't educate the reader when and why the design pattern should be used, and when not. The GoF list of design patterns is very much tightly coupled to the peculiarities of Java at the time the book was written. Many of the design patterns aren't necessary outside of that environment. For that reason, a lot of the design patterns in the book are either obsolete or so seamlessly built in to popular languages that it's not necessary to implement them as described in the book. Many of the more advanced "behavioral" patterns from the book are essentially ways to work around the fact that Java didn't have first class function, when that changes the design patterns that you end up with become very different. A lot of the GoF's list of design patterns just aren't that useful anymore in modern languages, even though many of them are as applicable as ever (modern languages bake iterator support into the language, for example). Additionally, the GoF design patterns break down into two categories: everyday patterns (like iterator, factory, proxy, or adapter) and sometimes patterns (like flyweight). This means that most of the patterns shouldn't be used in every project. Because the design patterns in the original book are somewhat out of date and because there's been so much cargo culting around the GoF patterns there's grown a substantial backlash against patterns. So people tend not to describe new patterns in such a way, even though they should. The concept itself is quite sound, but it requires diligent effort to ensure you're applying it well.
- rampage101 10y ago
hodgesrm 10y ago
> The problem with the design patterns books (including the GoF one) is that in the end they didn't have much influence. Really? The Gang of Four book was my favorite programming book from the 1990s. A lot of people read GoF as a cookbook which I think devalues it and leads to a very dogmatic design approach. The message I got from applying GoF over a period of years is that there are existing, flexible patterns that you can use to organize large object oriented systems, though they don't solve nearly every problem and you'll need to tune them for each design. Viewed that way it's a work that can give you inspiration for decades.

shagie 10y ago

Having seen far too many questions on sites about software design where someone starts out with "How do I use a Factory to solve...", I would contend that the GoF had far too much influence and missed the designer's original goals. > Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution. From an interview with Erich Gamma ( http://www.artima.com/lejava/articles/gammadp.html http://www.artima.com/lejava/articles/gammadp.html )

nickpsecurity 10y ago
Im leaning in that direction. Beginners did much better with methods like Cleanroom since it was all straight-forward decomposition of modules into easy-to-verify functions and acceptance tests. Amateurs trying to apply patterns often plaster them everywhere in designs that sometimes make structured programming in BASIC look more readable.

blub 10y ago

Some patterns have become parts of languages and libraries as those evolved. Subject-observer lives on in Qt's signals and slots and in general any signal/slot library. Command is basically operator() or std::function in C++. Null object is a useful little trick. I'd also add Facade and Strategy to your list. It's indeed not long but it does save some time when talking about design and various potential solutions. That's good enough for me. P.S: I think head first patterns should be preferred to the GoF book if one insists on learning from a book, but otherwise they can be grasped from a Wikipedia article.

leksak 10y ago
I think Game Programming Patterns is an excellent read for learning patterns

InclinedPlane 10y ago

The GoF design patterns book has two core, very closely related, problems. The first is that it doesn't make enough of an effort to present "design patterns" as a conceptual framework. Can you program without using design patterns? No, you cannot. You are always using design patterns whether you know it or not, you're just using ad hoc design patterns without realizing it when you don't think you're using patterns. The book's failure to elucidate commonly used ad hoc patterns as well as common anti-patterns is one of its principle shortcomings. This is something that the refactoring book did much better, by providing examples of how things can be engineered in different ways and why one way might be desirable over another (and how to transition between them). Instead the GoF book largely presents a canonical list of some design patterns, giving people the false impression that these are special and unique versus merely a sampling of ways one might do things. Additionally, the GoF book doesn't make it clear that each design pattern exists to work around specific constraints, and thus doesn't educate the reader when and why the design pattern should be used, and when not. The GoF list of design patterns is very much tightly coupled to the peculiarities of Java at the time the book was written. Many of the design patterns aren't necessary outside of that environment. For that reason, a lot of the design patterns in the book are either obsolete or so seamlessly built in to popular languages that it's not necessary to implement them as described in the book. Many of the more advanced "behavioral" patterns from the book are essentially ways to work around the fact that Java didn't have first class function, when that changes the design patterns that you end up with become very different. A lot of the GoF's list of design patterns just aren't that useful anymore in modern languages, even though many of them are as applicable as ever (modern languages bake iterator support into the language, for example). Additionally, the GoF design patterns break down into two categories: everyday patterns (like iterator, factory, proxy, or adapter) and sometimes patterns (like flyweight). This means that most of the patterns shouldn't be used in every project. Because the design patterns in the original book are somewhat out of date and because there's been so much cargo culting around the GoF patterns there's grown a substantial backlash against patterns. So people tend not to describe new patterns in such a way, even though they should. The concept itself is quite sound, but it requires diligent effort to ensure you're applying it well.

rampage101 10y ago

hodgesrm 10y ago

> The problem with the design patterns books (including the GoF one) is that in the end they didn't have much influence. Really? The Gang of Four book was my favorite programming book from the 1990s. A lot of people read GoF as a cookbook which I think devalues it and leads to a very dogmatic design approach. The message I got from applying GoF over a period of years is that there are existing, flexible patterns that you can use to organize large object oriented systems, though they don't solve nearly every problem and you'll need to tune them for each design. Viewed that way it's a work that can give you inspiration for decades.