[shagie]

I hope that you forgot the /s on that line.

Learning Patterns is one of the worst things to do without the experience in the problems that they solve since it results in coders who think that you write programs by hooking up some objects built with a Factory via xml (well, that was the thing when I wrote the post... its yaml now) and you've got a program - and that every program should be built of Factories and Observers and Facades and such and the dev goes about and builds the Patterns without actually solving the problem.

I have ranted on this before and that rant is at http://the-whiteboard.github.io/2016/09/02/patterns.html

I would also encourage reading https://www.artima.com/articles/how-to-use-design-patterns

> Bill Venners: Is the value of patterns, then, that in the real world when I feel a particular kind of pain I'll be able to reach for a known solution?

> Erich Gamma: This is definitely the way I'd recommend that people use patterns. Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. Because of this I really like to use patterns after the fact, refactoring to patterns. One comment I saw in a news group just after patterns started to become more popular was someone claiming that in a particular program they tried to use all 23 GoF patterns. They said they had failed, because they were only able to use 20. They hoped the client would call them again to come back again so maybe they could squeeze in the other 3.

> 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.

[junon]

> Trying to use all the patterns is a bad thing, because you will end up with synthetic designs

That's how you learn. We don't become seniors overnight.

[shagie]

One certainly doesn't become a senior overnight. However, the GoF book is not a book for fundamentals for a self taught developer.

I will also point out that the quote that I have and that you've quoted again is from Erich Gamma... of Design Patterns: Elements of Reusable Object-Oriented Software by by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

The GoF book on design patterns is a book for how to solve a common set of problems using these common solutions. What it is not is a "use these solutions in every well designed program".

My read on the OP's question is one of "how to become a junior programmer" - they can read code but don't write it well. The GoF is not the next book on that path. It is a book to read after you've been designing and understand the pains of writing and designing larger pieces of software... but if you're still working on "write something that solves a problem in 200 lines" the GoF will not provide any solutions for those problems. ... And if you do try to apply the GoF to the 200 line long problems you'll have contrived solutions that are a synthetic design that, in the words of Erich Gamma "speculative designs that have flexibility that no one needs. These days software is too complex."