"The Gang-of-Four idea is to discover existing patterns of software development. Then program people to implement them habitually"
Citation needed.
GoF's intention was to give people a tool for thinking about architecture and sharing their experiences with others. If people are "programmed to implement them habitually", that's some manager's fantasy and neither in the letter or spirit of Design Patterns.
It's be like seeing a programmer blindly use jQuery without understanding JavaScript, and blaming it on jQuery instead of the programmer. A tool that can be used badly, even one that lends itself to being used badly by a certain population, doesn't automatically mean the tool itself is rotten.
The issue is that in a lot of shops design patterns have turned into a religion and not just a tool to help thinking. I've seen managers like that.
If you didn't implement 15 different design patterns in this or that code base that was "bad design", even if it unnecessarily made the code more complex.
I've seen iterators classes written when a simple for loop would have done the trick. I've seen chains of responsibility implemented when a basic switch statement would have been enough. Of course the code wasn't meant to be refactored in anyways. In fact complexity led to inability to refactor anything as nobody had a clue what went where ... and of course to manage all that bullshit we had to write tons of factories, because instantiating a single useful object now took 30 lines of code ...
Agree, that's a real issue, just like managers who treat agile as a religion and sadly give a fundamentally good thing a bad name.
Good programmers know the importance of YAGNI and the root of all evil that is premature optimisation. They should be well equipped to avoid over-engineering while still getting the learning benefits of patterns.
Chain of responsibility, for example, is a pattern I learned via GoF, have found it to be useful on several occasions. I quite possibly never would have known about it otherwise. At best, it would be left to chance for me to stumble on it or refactor into it enough times to recognise the pattern.
I don't have the book handy, but I seem to remember somewhere early on they say something to the effect of "We find ourselves writing similar code in response to similar situations, so we've collected those strategies and put them in this book." I don't remember anything that sounded like "This is how you OO."
As others have pointed out, the book is nice because it gave rise to a common language for describing patterns, and it's much easier to understand code someone else wrote if you can divine intentions from variable and class names.
Citation needed.
GoF's intention was to give people a tool for thinking about architecture and sharing their experiences with others. If people are "programmed to implement them habitually", that's some manager's fantasy and neither in the letter or spirit of Design Patterns.
It's be like seeing a programmer blindly use jQuery without understanding JavaScript, and blaming it on jQuery instead of the programmer. A tool that can be used badly, even one that lends itself to being used badly by a certain population, doesn't automatically mean the tool itself is rotten.