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:
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.
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.)
"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.
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.
[+] [-] tptacek|16 years ago|reply
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.
[+] [-] cwinters|16 years ago|reply
[+] [-] sha90|16 years ago|reply
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.
[+] [-] jamesgolick|16 years ago|reply
> 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.