I always felt they got a bad rap. Most of the actual advice in the actual book was fine. However for some reason they get blamed for a lot of terrible 'advice' they never actually gave, often attributed to them by people who never actually read the book.
100% agreed. A lot of the patterns may feel heavy these days but I think that the majority have a place and are ingrained in our modern software. Without thinking about it much, we all use factories, singletons (yes, not always for the best), observers, builders, etc.
I think the bad rep comes from over use of these patterns that you see in mid 2000s Java2E "AbstractBeanFactoryBuilderBeanObserver" (hyperbole intended).
...maybe with Facade thrown in there too somewhere although I could be exaggerating with that.
When you see a classname like that the only rational response is to shrug, look at your watch and wonder how long you still have to work before you can get a strong drink.
Honestly I agree the problem with the GoF is not the content of the book itself but the fact that there is a certain type of personality which is very prevalent in software development (let's call them "pokemon trainers") who when confronted with a classification like that just have to "catch them all" (or in this case get them into every program as often as possible).
As a field guide to spotting and understanding common idioms it's fine. The problem is it's like showing a lexicon of cliches to a creative writing night school class. You know from then on about 90% of the material you read is going to be "It was a dark and stormy night... etc etc".
I just can't really ever forgive them for unleashing that particular demon.
Comments
(curses be upon them etc etc)
I always felt they got a bad rap. Most of the actual advice in the actual book was fine. However for some reason they get blamed for a lot of terrible 'advice' they never actually gave, often attributed to them by people who never actually read the book.
100% agreed. A lot of the patterns may feel heavy these days but I think that the majority have a place and are ingrained in our modern software. Without thinking about it much, we all use factories, singletons (yes, not always for the best), observers, builders, etc.
I think the bad rep comes from over use of these patterns that you see in mid 2000s Java2E "AbstractBeanFactoryBuilderBeanObserver" (hyperbole intended).
My fave that I ever saw in real production code involved Builder, factory and iterator with at least two of them repeated. So it was something like
AbstractWidgetBuilderFactoryBuilderIteratorFactory
...maybe with Facade thrown in there too somewhere although I could be exaggerating with that.
When you see a classname like that the only rational response is to shrug, look at your watch and wonder how long you still have to work before you can get a strong drink.
Honestly I agree the problem with the GoF is not the content of the book itself but the fact that there is a certain type of personality which is very prevalent in software development (let's call them "pokemon trainers") who when confronted with a classification like that just have to "catch them all" (or in this case get them into every program as often as possible).
As a field guide to spotting and understanding common idioms it's fine. The problem is it's like showing a lexicon of cliches to a creative writing night school class. You know from then on about 90% of the material you read is going to be "It was a dark and stormy night... etc etc".
I just can't really ever forgive them for unleashing that particular demon.