3 ms·

Let's Do Some Engineering Pt. 1: Design Patterns

9 points by sha90 17y ago

tptacek 17y ago
Painful and a little embarrassing. The GoF patterns exist primarily to make up for the fact that you're not in Ruby. The timeless response to any article referencing them: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/ Sort of funny that he mentioned dependency injection as a benefit of one of these approaches; building things around DI was one of the reasons net-ssh got rewritten. When you find yourself writing Java in Ruby or Python, stop, take a step back, and reconsider.
- sha90 17y ago
  "GoF patterns exist primarily to make up for the fact that you're not in Ruby"- this is the epitome of ignorance and the exact denial referred to in the article. I must have missed that part in Design Patterns that said "if you use Ruby you should not use this book". But hey, I guess the Ruby stdlib includes the "Singleton" pattern for fun right? Not because you'd use it, or anything. Same with delegates. And I guess Rails didn't actually implement Martin Fowler's Active Record, Action Controller and MVC patterns? You just dreamed those. Wake up. Your comment is painful and a little embarrassing. Design patterns are language independent. They are not implementation, they are descriptions. They can be used in any language, and they are used in Ruby.
  - kuzux 17y ago
    First of all, ActiveRecord is not a GoF pattern and its intent is not trying to implement the lacking dynamic features in static languages. Thus, it's not trivial or a source of unneeded complexity in ruby. And so is MVC(Actually, MVC is quite different from the other "Design Patterns" as it covers the entire architecture of the system instead of just a part of it). The point is, most GoF patterns(like factory, builder, strategy, facade etc.) are trivial in "dynamic" languages like ruby and lisp and strictly applying those static-language-origin patterns cause nothing but unneeded complexity in ruby.
    - sha90 17y ago
      I never claimed Active Record was a GoF pattern, in fact, I'm sure it would be easy to read that I cited "Martin Fowler". Whether or not it's GoF, Fowler or any other source doesn't change that it's a design pattern, though. GoF patterns are no different from Fowler's EAA patterns. One is not meant for static languages while the other is meant for dynamic. That's not how patterns work. If you think that GoF patterns were specifically made for Java, you should look at the publishing date of the book. You might also consider that the book uses Smalltalk in its examples. PS. Smalltalk is dynamic. The problem with your argument is that the "triviality" of their implementation has nothing to do with whether or not you use them. class X < DelegateClass(String); end This is using the delegate pattern. It's pretty damn trivial to implement. But we are using the delegate pattern. This is a fact. We can do the same for singletons, factories, facades, visitors and strategies. How you implement them does not define whether or not you use them. Whether or not you tell people you use them is what matters, because patterns are about communication, not implementation. If you don't understand this simple concept then you're completely missing the point of design patterns. Yes, you can implement the Adapter pattern in Ruby without doing anything explicit-- that doesn't mean you didn't use the Adapter pattern. This is where denial kicks in. If you say "I don't use strategy patterns, I use DYNAMIC PROGRAMMING!" you're seriously deluding yourself.
      - tptacek 17y ago
        You're playing semantic games. If we accept your terms, we're adopting the GoF patterns any time we use "method_missing". You're also arguing with a straw man. The original idea behind the "Design Patterns movement" was to provide a common language for describing recurring concepts in software design. It's the same idea behind Alexander's "A Pattern Language", which is something else you should read. Nobody is arguing that describing things a little more rigorously is bad. But a lot of people have problems with the way "engineers" and "architects" abuse the pattern concept. Alexander did not write a book that claimed you could build an entire city by picking out a "44. Local Town Hall" and mixing it with a "69. Public Outdoor Room". He had an idea, that the cart was dragging the horse in architecture, and attempted to use vocabulary to reframe the discussion about why specific choices were being made. The Gang of Four introduced a minor corruption in that approach --- they had no fundamental thesis about how software should be designed, only a notion that there was folkloric knowledge that should be captured and named --- but their followers completed the corruption wholeheartedly. Instead of a language describing software, the GoF patterns became a perscription for building it. And so we have Ruby code that includes a "singleton" module into classes, and SOAP4R code that includes "factory" classes (note again how ruby already transparently supports the abstract factory concept), and people argung that we should start "doing a little engineering" by pulling these clumsy ideas back off the shelf. I can't argue this any better than Norvig can. In fact, I'll invoke him again by suggesting that you don't want to end up like Norvig's "opponent" in the sudoku-solving contet.
  - tptacek 17y ago
    There is a world of difference between what Schmidt tried (and failed) to do with Pattern Oriented Software Architecure and what Java programmers managed to do with the Gang of Four patterns. You really, really ought to follow that Norvig link I posted. There is more insight and utility in that 10 minute read than in everything Fowler wrote. There is a "Singleton" in the Ruby standard library, but since every Ruby class inherently includes a "singleton", you'd be embarassing yourself to use it. Note that it occurs nowhere in current Rails. Note also that "Singleton" is notoriously derided as an example of how superficial some of the GoF patterns are; it is, at its core, a puffed-up way of saying "global variable". Maybe a better name for it would be "very global variable". Regardless, the twin problems with this blog post remain: * The idea behind design patterns isn't that they give you a library of pre-built components that you can pick up off the shelf and use to assemble complete programs. But that's exactly how this blog post uses them. * The GoF design patterns in particular describe ways to patch around the weaknesses of C++ and Java; they are, as Norvig writes, transparently implemented in modern languages, and reimplementing them is something akin to writing your own string matching or filename globbing code.
    - sha90 17y ago
      "Maybe a better name for it would be "very global variable"." The better name for it already exists: it is the Singleton pattern, because OOP software developers already understand this concept. You don't need to invent new names, this is why patterns exist. Also note that whether or not you use the "Singleton" mixin in Ruby, you are still using the Singleton pattern whenever you define a class with no constructor. Yes, you can do this without "include Singleton"; no, this does not mean you're magically using some new concept nobody's thought of before. You're still using Singletons. * The blog post doesn't use any patterns at all. Given that there are no code examples or suggestions, I don't see how you came to this conclusion. The blog post never tells you how to use patterns, it tells you why you use patterns. Where does it advise you to "pick up components and use them to assemble complete programs"? * Java did not exist when GoF wrote Design Patterns, so it clearly was not addressing any weaknesses of that language. Your point is DOA and you seem to be pulling this out of your ass. But, to elaborate: GoF isn't describing ways to patch any languages, it's describing ways to attack software problems. The idea of using a Strategy pattern (for instance) is universal among any programming language, it has absolutely nothing to do with code. So is using a factory method. Ever used `ActiveRecord.build` or 'create_with_...'? That's a factory method. The same concept applies with adapters, facades, et al. How you implement the pattern is completely irrelevant to the entire book. You could do it with dynamic dispatch or classes, the book doesn't define the patterns by their implementations. The point is you're using them. Pretending you're not is some kind of childish posturing so you can tell yourself you're "not doing anymore Java". I'm sorry you experienced your Java nightmares, but design patterns have nothing to do with that language.
- cwinters 17y ago
  True for some patterns, but not all. Unit of Work, for example, is a useful abstraction no matter what framework or language you're using. (It's not a GoF pattern, but it was brought up in the OP.)
jamesgolick 17y ago
What's painful and embarrassing is when somebody who didn't actually read the article calls it "painful and embarrassing". > Patterns are still patterns whether you acknowledge them or not, and they are not defined by the LOC or number of classes they require in language X. > Refusing to admit that patterns are used hurts your development team and the community, because patterns (simply identifying them) serve a very important purpose. > Well, design patterns are just like [agile] metaphors, but they are meant for code, not UI. > For instance, consider the factory pattern versus the builder pattern. Both are concerned with creating objects, but a builder is also concerned with the assembling of the object. This is a relatively subtle but pretty noticeable difference. Telling someone you are using a "builder pattern" should immediately ring a bell in their heads saying, "oh, it’s not just a factory". Patterns are specific nomenclature not implementation.

9 points by sha90 17y ago

Painful and a little embarrassing. The GoF patterns exist primarily to make up for the fact that you're not in Ruby. The timeless response to any article referencing them: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/ Sort of funny that he mentioned dependency injection as a benefit of one of these approaches; building things around DI was one of the reasons net-ssh got rewritten. When you find yourself writing Java in Ruby or Python, stop, take a step back, and reconsider.

sha90 17y ago
"GoF patterns exist primarily to make up for the fact that you're not in Ruby"- this is the epitome of ignorance and the exact denial referred to in the article. I must have missed that part in Design Patterns that said "if you use Ruby you should not use this book". But hey, I guess the Ruby stdlib includes the "Singleton" pattern for fun right? Not because you'd use it, or anything. Same with delegates. And I guess Rails didn't actually implement Martin Fowler's Active Record, Action Controller and MVC patterns? You just dreamed those. Wake up. Your comment is painful and a little embarrassing. Design patterns are language independent. They are not implementation, they are descriptions. They can be used in any language, and they are used in Ruby.
- kuzux 17y ago
  First of all, ActiveRecord is not a GoF pattern and its intent is not trying to implement the lacking dynamic features in static languages. Thus, it's not trivial or a source of unneeded complexity in ruby. And so is MVC(Actually, MVC is quite different from the other "Design Patterns" as it covers the entire architecture of the system instead of just a part of it). The point is, most GoF patterns(like factory, builder, strategy, facade etc.) are trivial in "dynamic" languages like ruby and lisp and strictly applying those static-language-origin patterns cause nothing but unneeded complexity in ruby.
  - sha90 17y ago
    I never claimed Active Record was a GoF pattern, in fact, I'm sure it would be easy to read that I cited "Martin Fowler". Whether or not it's GoF, Fowler or any other source doesn't change that it's a design pattern, though. GoF patterns are no different from Fowler's EAA patterns. One is not meant for static languages while the other is meant for dynamic. That's not how patterns work. If you think that GoF patterns were specifically made for Java, you should look at the publishing date of the book. You might also consider that the book uses Smalltalk in its examples. PS. Smalltalk is dynamic. The problem with your argument is that the "triviality" of their implementation has nothing to do with whether or not you use them. class X < DelegateClass(String); end This is using the delegate pattern. It's pretty damn trivial to implement. But we are using the delegate pattern. This is a fact. We can do the same for singletons, factories, facades, visitors and strategies. How you implement them does not define whether or not you use them. Whether or not you tell people you use them is what matters, because patterns are about communication, not implementation. If you don't understand this simple concept then you're completely missing the point of design patterns. Yes, you can implement the Adapter pattern in Ruby without doing anything explicit-- that doesn't mean you didn't use the Adapter pattern. This is where denial kicks in. If you say "I don't use strategy patterns, I use DYNAMIC PROGRAMMING!" you're seriously deluding yourself.
    - tptacek 17y ago
      You're playing semantic games. If we accept your terms, we're adopting the GoF patterns any time we use "method_missing". You're also arguing with a straw man. The original idea behind the "Design Patterns movement" was to provide a common language for describing recurring concepts in software design. It's the same idea behind Alexander's "A Pattern Language", which is something else you should read. Nobody is arguing that describing things a little more rigorously is bad. But a lot of people have problems with the way "engineers" and "architects" abuse the pattern concept. Alexander did not write a book that claimed you could build an entire city by picking out a "44. Local Town Hall" and mixing it with a "69. Public Outdoor Room". He had an idea, that the cart was dragging the horse in architecture, and attempted to use vocabulary to reframe the discussion about why specific choices were being made. The Gang of Four introduced a minor corruption in that approach --- they had no fundamental thesis about how software should be designed, only a notion that there was folkloric knowledge that should be captured and named --- but their followers completed the corruption wholeheartedly. Instead of a language describing software, the GoF patterns became a perscription for building it. And so we have Ruby code that includes a "singleton" module into classes, and SOAP4R code that includes "factory" classes (note again how ruby already transparently supports the abstract factory concept), and people argung that we should start "doing a little engineering" by pulling these clumsy ideas back off the shelf. I can't argue this any better than Norvig can. In fact, I'll invoke him again by suggesting that you don't want to end up like Norvig's "opponent" in the sudoku-solving contet.
- tptacek 17y ago
  There is a world of difference between what Schmidt tried (and failed) to do with Pattern Oriented Software Architecure and what Java programmers managed to do with the Gang of Four patterns. You really, really ought to follow that Norvig link I posted. There is more insight and utility in that 10 minute read than in everything Fowler wrote. There is a "Singleton" in the Ruby standard library, but since every Ruby class inherently includes a "singleton", you'd be embarassing yourself to use it. Note that it occurs nowhere in current Rails. Note also that "Singleton" is notoriously derided as an example of how superficial some of the GoF patterns are; it is, at its core, a puffed-up way of saying "global variable". Maybe a better name for it would be "very global variable". Regardless, the twin problems with this blog post remain: * The idea behind design patterns isn't that they give you a library of pre-built components that you can pick up off the shelf and use to assemble complete programs. But that's exactly how this blog post uses them. * The GoF design patterns in particular describe ways to patch around the weaknesses of C++ and Java; they are, as Norvig writes, transparently implemented in modern languages, and reimplementing them is something akin to writing your own string matching or filename globbing code.
  - sha90 17y ago
    "Maybe a better name for it would be "very global variable"." The better name for it already exists: it is the Singleton pattern, because OOP software developers already understand this concept. You don't need to invent new names, this is why patterns exist. Also note that whether or not you use the "Singleton" mixin in Ruby, you are still using the Singleton pattern whenever you define a class with no constructor. Yes, you can do this without "include Singleton"; no, this does not mean you're magically using some new concept nobody's thought of before. You're still using Singletons. * The blog post doesn't use any patterns at all. Given that there are no code examples or suggestions, I don't see how you came to this conclusion. The blog post never tells you how to use patterns, it tells you why you use patterns. Where does it advise you to "pick up components and use them to assemble complete programs"? * Java did not exist when GoF wrote Design Patterns, so it clearly was not addressing any weaknesses of that language. Your point is DOA and you seem to be pulling this out of your ass. But, to elaborate: GoF isn't describing ways to patch any languages, it's describing ways to attack software problems. The idea of using a Strategy pattern (for instance) is universal among any programming language, it has absolutely nothing to do with code. So is using a factory method. Ever used `ActiveRecord.build` or 'create_with_...'? That's a factory method. The same concept applies with adapters, facades, et al. How you implement the pattern is completely irrelevant to the entire book. You could do it with dynamic dispatch or classes, the book doesn't define the patterns by their implementations. The point is you're using them. Pretending you're not is some kind of childish posturing so you can tell yourself you're "not doing anymore Java". I'm sorry you experienced your Java nightmares, but design patterns have nothing to do with that language.
cwinters 17y ago
True for some patterns, but not all. Unit of Work, for example, is a useful abstraction no matter what framework or language you're using. (It's not a GoF pattern, but it was brought up in the OP.)

jamesgolick 17y ago

What's painful and embarrassing is when somebody who didn't actually read the article calls it "painful and embarrassing". > Patterns are still patterns whether you acknowledge them or not, and they are not defined by the LOC or number of classes they require in language X. > Refusing to admit that patterns are used hurts your development team and the community, because patterns (simply identifying them) serve a very important purpose. > Well, design patterns are just like [agile] metaphors, but they are meant for code, not UI. > For instance, consider the factory pattern versus the builder pattern. Both are concerned with creating objects, but a builder is also concerned with the assembling of the object. This is a relatively subtle but pretty noticeable difference. Telling someone you are using a "builder pattern" should immediately ring a bell in their heads saying, "oh, it’s not just a factory". Patterns are specific nomenclature not implementation.