3 ms·

That depends on how much you value having names for high-level programming patterns, and how long you've been coding before you read it. I think it is great fo

That depends on how much you value having names for high-level programming patterns, and how long you've been coding before you read it. I think it is great for junior developers to read so they can get an idea of what to expect, and how to apply encapsulation and real-world OOP. This book is more like the urbandictionary.com than Strunk & White, and some people get that backwards.

gruseom 18y ago
I think it is great for junior developers to read I don't think so. In my observation, the primary effect of Design Patterns was to popularize a way of thinking (programming as the stringing-together of predefined constructs) that led a lot of people to write hyper-patterny bad code. This stuff, with its layers of tangled pseudo-abstraction, turned out to be harder to read, work with, and clean up than the plain old bad code they were writing before. But it felt sophisticated to the ones producing it, and they thought they were doing things the "right" way. Of course it's not the authors' fault how others used their book. But as Tim Lister cleverly said (about something else), "if everybody gets it wrong there must be something wrong with it." And I do think there was something misleading about the model the book promoted. For example, the GoF "patterns" are not at all the same kind of thing, something that the technical format of the book obscured. Some (Decorator) are so simple and ubiquitous that calling them a pattern is silly (like talking about a "parameter" pattern). Others (Iterator) are true formalisms which, as has been pointed out many times, can and should be dealt with at a language level (for the same reason we don't have a "subroutine" pattern). Others (Interpreter) are so general that talking about them as patterns, let alone trying to create a canonical implementation of them, is pointless. Others (Abstract Factory) sound good at first, but are so different every time that they can't be effectively reasoned about (and god, did people make a mess with those). But Design Patterns promoted the idea that this was a collection of similar mechanisms, like tools in a toolbox, or a collection of standardized parts that the programmer would recognize the need for and plug in where appropriate. It sounded good, and came in a pseudo-technical encoding which was the real genius of the book from a sales point of view. But in my observation the whole approach broke down rather quickly in practice. (Edited in a feeble attempt to make shorter.)
- aaronblohowiak 18y ago
  Thanks for your reasoned and thoughtful reply. I've voted you up. However, I disagree with your central thesis. Programming is the stringing together of predefined constructs. However, like all matters of taste, the hard part is when things are appropriate. Reading the rest of your post as "GoF does not adequately teach when to use redirection, and other techniques of abstraction, leading to sophistry instead of sophistication," I completely agree with what you have to say. The junior programmers that I know who have read GoF DP have been subject to my endless bashing over the head with the simplicity stick, and so I hope that they use indirection and abstract techniques only as appropriate.
  - gruseom 18y ago
    I disagree with your central thesis. Programming is the stringing together of predefined constructs. I see what you mean. Yes, but in not the sense I meant. My point is that the predefined constructs in the GoF book are at varying levels of abstraction and granularity, and mostly can't effectively be strung together in the way the book implied. That's my attempt to explain why people mostly created messes when they tried (an empirical observation). If DP were actually about "indirection and abstract techniques" per se, that would be fine. But it's more than that. It's a cookbook of specific clumps of indirection and abstraction. And I don't think programs can be decomposed into those clumps or composed out of them.

gruseom 18y ago

I think it is great for junior developers to read I don't think so. In my observation, the primary effect of Design Patterns was to popularize a way of thinking (programming as the stringing-together of predefined constructs) that led a lot of people to write hyper-patterny bad code. This stuff, with its layers of tangled pseudo-abstraction, turned out to be harder to read, work with, and clean up than the plain old bad code they were writing before. But it felt sophisticated to the ones producing it, and they thought they were doing things the "right" way. Of course it's not the authors' fault how others used their book. But as Tim Lister cleverly said (about something else), "if everybody gets it wrong there must be something wrong with it." And I do think there was something misleading about the model the book promoted. For example, the GoF "patterns" are not at all the same kind of thing, something that the technical format of the book obscured. Some (Decorator) are so simple and ubiquitous that calling them a pattern is silly (like talking about a "parameter" pattern). Others (Iterator) are true formalisms which, as has been pointed out many times, can and should be dealt with at a language level (for the same reason we don't have a "subroutine" pattern). Others (Interpreter) are so general that talking about them as patterns, let alone trying to create a canonical implementation of them, is pointless. Others (Abstract Factory) sound good at first, but are so different every time that they can't be effectively reasoned about (and god, did people make a mess with those). But Design Patterns promoted the idea that this was a collection of similar mechanisms, like tools in a toolbox, or a collection of standardized parts that the programmer would recognize the need for and plug in where appropriate. It sounded good, and came in a pseudo-technical encoding which was the real genius of the book from a sales point of view. But in my observation the whole approach broke down rather quickly in practice. (Edited in a feeble attempt to make shorter.)

aaronblohowiak 18y ago
Thanks for your reasoned and thoughtful reply. I've voted you up. However, I disagree with your central thesis. Programming is the stringing together of predefined constructs. However, like all matters of taste, the hard part is when things are appropriate. Reading the rest of your post as "GoF does not adequately teach when to use redirection, and other techniques of abstraction, leading to sophistry instead of sophistication," I completely agree with what you have to say. The junior programmers that I know who have read GoF DP have been subject to my endless bashing over the head with the simplicity stick, and so I hope that they use indirection and abstract techniques only as appropriate.
- gruseom 18y ago
  I disagree with your central thesis. Programming is the stringing together of predefined constructs. I see what you mean. Yes, but in not the sense I meant. My point is that the predefined constructs in the GoF book are at varying levels of abstraction and granularity, and mostly can't effectively be strung together in the way the book implied. That's my attempt to explain why people mostly created messes when they tried (an empirical observation). If DP were actually about "indirection and abstract techniques" per se, that would be fine. But it's more than that. It's a cookbook of specific clumps of indirection and abstraction. And I don't think programs can be decomposed into those clumps or composed out of them.