3 ms·

"Design Patterns" is poison.

mullr 19y ago
To the weak of mind, perhaps. I believe that patterns are useful and beneficial in moderation. This requires a degree of understanding that some do not have, leading to pattern hell. The analogies to alcohol are disturbing.
- thaumaturgy 19y ago
  Admittedly, I haven't read the texts on design patterns, and have only a cursory knowledge of what they're about. So, I'm about to commit the cardinal sin of talking on a subject that I don't know intimately. Near as I can tell, design patterns are just ways of vaguely describing common solutions to common problems. They say, "You might try to solve problem X in some language by creating an object that does Y." In lieu of actually understanding the specific problem they're facing, the inexperienced or less skilled programmer then looks through their dictionary of design patterns, finds something that sounds like it fits, and then proceeds to throw some very generic code at their problem until it goes away. This strikes me as very similar to the problem Feynman discussed in "Surely You're Joking", when he worked as a professor in Brazil and came to realize that, on a national basis, the students had all been taught to memorize entire books of facts, but hadn't done experiments and didn't understand the concepts behind the things they were taught.
  - Tichy 19y ago
    I recommend reading a text on design patterns. The Brazil example falls short, because people having no understandings of concepts doesn't invalidate the concepts themselves.
    - thaumaturgy 19y ago
      Design patterns are on my reading list, but these days that list is much larger than my available free time. I agree with you, actually. My point wasn't that the design patterns themselves are wrong, or necessarily bad, it was that (I think) they'll tend to get used in situations where the programmer doesn't understand the immediate problem or solution well enough to deal with it directly. Anecdotally, this came up somewhat recently when the question of whether or not it's "OK" to return early from a function got briefly passed around the net. I noticed a lot of instances where people were coming up with some pretty absurd reasoning to justify always doing it one particular way, the 'textbook' way if you will. Myself, I think it's _sometimes_ OK to return early from a function. It depends on what you're doing. You have to understand the situation you're looking at, and all of the various circumstances around it. So, the idea of "never return early from a function" isn't necessarily wrong, but it does indicate that the programmer probably doesn't really understand what they're doing.
      - Tichy 19y ago
        It's been a while that I read it, but I thought the original "Design Patterns" book was pretty good. You won't find something like the "return early from function" in it. I think it is best to read the original design patterns book, not the language specific clones (ie not "Design Patterns for Java" etc). Most patterns in the book are not that trivial, so I don't think you can apply them without understanding them (in general).
KirinDave 19y ago
Agreed. People read it and thing they're reading a how-to rather than a dictionary.
- mynameishere 19y ago
  I don't want to go into details, because things would quickly get biographical, but the real danger is that the book is written with faux-scientific verbiage, and uses that to trick weak-minded people into thinking that they are reading a scientific text. This is an old trick of conmen and cultists and when it works it isn't pretty.
  - bayareaguy 19y ago
    You say you don't want to go into the details but you really should in order to strengthen your argument. At the moment you're just using DH2 (Responding to Tone), DH1 (Ad Hominem) and perhaps a little DH0 (Name calling). If you really think the GoF are aiding conmen in tricking the weak-minded, then please substanciate that.
    - mynameishere 19y ago
      I don't have the book to quote it. But roughly, here is how it works: What is an "Iterator"? It's an object that contains functionality to retrieve objects from a container. Period. The end. Now, what is an "Iterator Pattern"? (Again, I don't have the book, so...) I think it is about 10-15 pages of how to define, describe, document, specify, graph, implement, re-use, contextualize and otherwise belabour the Iterator object. But, at the end of the day, an "Iterator" is simply the next-next-next functionality moved from the linked list to another place. That's all it ever is, in practice. The book makes things worse by using PhD-dissertation levels of vocabulary and grammatical structures to describe simple, simple concepts. This gives confusion to people who don't see through the bull, and when they say "Aha! I understand Iterators!", they believe they've unriddled a mystery, and so become "educators" and "advocates" on behalf of others. I speak from experience, and have no statistics on this.
      - 19y ago
sah 19y ago
I strongly agree. This is one of the better essays on why: http://blog.plover.com/2006/09/11/ http://blog.plover.com/2006/09/11/ One point it unfortunately doesn't cover is the large percentage of Go4 patterns that are just plain bad ideas. Singleton, for example, should just never be used: it's like relying too much on global variables, but worse.
- bayareaguy 19y ago
  But some of the very things you need to live will kill you if you consume too much of them. The problem is people often use the Design Patterns book as a design manual but that's not what it really is - it's an attempt to catagorize ideas. The very fact that you used the term Singleton means that now you and I can argue the merits of using that pattern in different situations. Would you rather us attempt to do that without common terminology?
  - sah 19y ago
    There's nothing wrong with having common terminology. But when people are being taught about bad ideas without any cautionary comments, that's a problem. By the same token, there's nothing wrong with knowing what a goto statement is. But I'm glad we don't have a popular book that implicitly advocates its use, or college classes that teach it to students as if it's the state of the art in control flow.
- boucher 19y ago
  I agree that the book is way too overused. I was immediately turned off when I would interview people who started talking in design patterns (not to mention people who would say the wrong ones). However, I think there are completely valid uses of the "Singleton" concept. It can be an elegant solution to a lot of problems.
  - sah 19y ago
    I'd like to hear about valid uses of Singleton. I'm not completely sure there aren't any, but I don't think I've ever seen one.
phaedrus 19y ago
I modded you up even though I disagree with you. Using design patterns really helped me in a large project I did in C# two years ago - although I must admit I used the friendlier Head First Design Patterns as my reference rather than the original Design Patterns book. I honestly think I would not have been able to do the project without the aid of design patterns. The project's architect was living too high in the clouds to grasp why his architectures were unimplementable, yet tried to micromanage the implementation as well. He continually specified implementation details which violated basic constraints of the language syntax and the static type system (like asking for multiple inheritance in C#). So I would use design patterns to get around a language limitation to do something close to what he wanted. Since he didn't understand design patterns, he found my explanation of how the design pattern accomplished the trick impenetrable enough to just leave it alone. It backfired on me when he learned the Singleton pattern (which he kept mistakenly referring to as the "Simpleton" pattern), and started insisting that every object should be a "Simpleton". Anyhow so the reason I didn't downmod you, is that I do think design patterns are useful, but they fix a problem which is partly that the language is broken, and partly a people problem.

mullr 19y ago

To the weak of mind, perhaps. I believe that patterns are useful and beneficial in moderation. This requires a degree of understanding that some do not have, leading to pattern hell. The analogies to alcohol are disturbing.

thaumaturgy 19y ago
Admittedly, I haven't read the texts on design patterns, and have only a cursory knowledge of what they're about. So, I'm about to commit the cardinal sin of talking on a subject that I don't know intimately. Near as I can tell, design patterns are just ways of vaguely describing common solutions to common problems. They say, "You might try to solve problem X in some language by creating an object that does Y." In lieu of actually understanding the specific problem they're facing, the inexperienced or less skilled programmer then looks through their dictionary of design patterns, finds something that sounds like it fits, and then proceeds to throw some very generic code at their problem until it goes away. This strikes me as very similar to the problem Feynman discussed in "Surely You're Joking", when he worked as a professor in Brazil and came to realize that, on a national basis, the students had all been taught to memorize entire books of facts, but hadn't done experiments and didn't understand the concepts behind the things they were taught.
- Tichy 19y ago
  I recommend reading a text on design patterns. The Brazil example falls short, because people having no understandings of concepts doesn't invalidate the concepts themselves.
  - thaumaturgy 19y ago
    Design patterns are on my reading list, but these days that list is much larger than my available free time. I agree with you, actually. My point wasn't that the design patterns themselves are wrong, or necessarily bad, it was that (I think) they'll tend to get used in situations where the programmer doesn't understand the immediate problem or solution well enough to deal with it directly. Anecdotally, this came up somewhat recently when the question of whether or not it's "OK" to return early from a function got briefly passed around the net. I noticed a lot of instances where people were coming up with some pretty absurd reasoning to justify always doing it one particular way, the 'textbook' way if you will. Myself, I think it's _sometimes_ OK to return early from a function. It depends on what you're doing. You have to understand the situation you're looking at, and all of the various circumstances around it. So, the idea of "never return early from a function" isn't necessarily wrong, but it does indicate that the programmer probably doesn't really understand what they're doing.
    - Tichy 19y ago
      It's been a while that I read it, but I thought the original "Design Patterns" book was pretty good. You won't find something like the "return early from function" in it. I think it is best to read the original design patterns book, not the language specific clones (ie not "Design Patterns for Java" etc). Most patterns in the book are not that trivial, so I don't think you can apply them without understanding them (in general).

KirinDave 19y ago

Agreed. People read it and thing they're reading a how-to rather than a dictionary.

mynameishere 19y ago
I don't want to go into details, because things would quickly get biographical, but the real danger is that the book is written with faux-scientific verbiage, and uses that to trick weak-minded people into thinking that they are reading a scientific text. This is an old trick of conmen and cultists and when it works it isn't pretty.
- bayareaguy 19y ago
  You say you don't want to go into the details but you really should in order to strengthen your argument. At the moment you're just using DH2 (Responding to Tone), DH1 (Ad Hominem) and perhaps a little DH0 (Name calling). If you really think the GoF are aiding conmen in tricking the weak-minded, then please substanciate that.
  - mynameishere 19y ago
    I don't have the book to quote it. But roughly, here is how it works: What is an "Iterator"? It's an object that contains functionality to retrieve objects from a container. Period. The end. Now, what is an "Iterator Pattern"? (Again, I don't have the book, so...) I think it is about 10-15 pages of how to define, describe, document, specify, graph, implement, re-use, contextualize and otherwise belabour the Iterator object. But, at the end of the day, an "Iterator" is simply the next-next-next functionality moved from the linked list to another place. That's all it ever is, in practice. The book makes things worse by using PhD-dissertation levels of vocabulary and grammatical structures to describe simple, simple concepts. This gives confusion to people who don't see through the bull, and when they say "Aha! I understand Iterators!", they believe they've unriddled a mystery, and so become "educators" and "advocates" on behalf of others. I speak from experience, and have no statistics on this.
    - 19y ago

sah 19y ago

I strongly agree. This is one of the better essays on why: http://blog.plover.com/2006/09/11/ http://blog.plover.com/2006/09/11/ One point it unfortunately doesn't cover is the large percentage of Go4 patterns that are just plain bad ideas. Singleton, for example, should just never be used: it's like relying too much on global variables, but worse.

bayareaguy 19y ago
But some of the very things you need to live will kill you if you consume too much of them. The problem is people often use the Design Patterns book as a design manual but that's not what it really is - it's an attempt to catagorize ideas. The very fact that you used the term Singleton means that now you and I can argue the merits of using that pattern in different situations. Would you rather us attempt to do that without common terminology?
- sah 19y ago
  There's nothing wrong with having common terminology. But when people are being taught about bad ideas without any cautionary comments, that's a problem. By the same token, there's nothing wrong with knowing what a goto statement is. But I'm glad we don't have a popular book that implicitly advocates its use, or college classes that teach it to students as if it's the state of the art in control flow.
boucher 19y ago
I agree that the book is way too overused. I was immediately turned off when I would interview people who started talking in design patterns (not to mention people who would say the wrong ones). However, I think there are completely valid uses of the "Singleton" concept. It can be an elegant solution to a lot of problems.
- sah 19y ago
  I'd like to hear about valid uses of Singleton. I'm not completely sure there aren't any, but I don't think I've ever seen one.

phaedrus 19y ago

I modded you up even though I disagree with you. Using design patterns really helped me in a large project I did in C# two years ago - although I must admit I used the friendlier Head First Design Patterns as my reference rather than the original Design Patterns book. I honestly think I would not have been able to do the project without the aid of design patterns. The project's architect was living too high in the clouds to grasp why his architectures were unimplementable, yet tried to micromanage the implementation as well. He continually specified implementation details which violated basic constraints of the language syntax and the static type system (like asking for multiple inheritance in C#). So I would use design patterns to get around a language limitation to do something close to what he wanted. Since he didn't understand design patterns, he found my explanation of how the design pattern accomplished the trick impenetrable enough to just leave it alone. It backfired on me when he learned the Singleton pattern (which he kept mistakenly referring to as the "Simpleton" pattern), and started insisting that every object should be a "Simpleton". Anyhow so the reason I didn't downmod you, is that I do think design patterns are useful, but they fix a problem which is partly that the language is broken, and partly a people problem.