Sign in with Facebook
Michael's Reviews > Design Patterns: Elements of Reusable Object-Oriented Software
Design Patterns: Elements of Reusable Object-Oriented Software
by
by
I know this is an unpopular opinion, but I think the concept of a design pattern is just this side of bogus.
Part of the issue is that the languages the industry has chosen have weak powers of abstraction and thus these patterns seem necessary. Perhaps it's becoming a cliche (or became one 10 years ago?), but I'm sure some haven't yet been exposed to this thought: in a decent language like Lisp, most of these design patterns are trivial. The patterns are only there to make up for the problems with the languages of choice.
For me another issue is that the idea of design patterns is firmly linked in my brain with absurd Java APIs that require me to deal with XYZManagers and ABCHandlers and twenty different classes all for something that anyone sane would have just provided a handful of simple functions for.
On the other hand, this post by Richard Gabriel is interesting:
http://groups.google.com/group/comp.l...
Perhaps design patterns are worth looking into after all, just not in this book.
Part of the issue is that the languages the industry has chosen have weak powers of abstraction and thus these patterns seem necessary. Perhaps it's becoming a cliche (or became one 10 years ago?), but I'm sure some haven't yet been exposed to this thought: in a decent language like Lisp, most of these design patterns are trivial. The patterns are only there to make up for the problems with the languages of choice.
For me another issue is that the idea of design patterns is firmly linked in my brain with absurd Java APIs that require me to deal with XYZManagers and ABCHandlers and twenty different classes all for something that anyone sane would have just provided a handful of simple functions for.
On the other hand, this post by Richard Gabriel is interesting:
http://groups.google.com/group/comp.l...
Perhaps design patterns are worth looking into after all, just not in this book.
Sign into Goodreads to see if any of your friends have read
Design Patterns.
Sign In »
Reading Progress
Finished Reading
January 28, 2008
– Shelved
April 29, 2009
– Shelved as:
code
May 1, 2010
– Shelved as:
nonfiction
Comments Showing 1-5 of 5 (5 new)
date
newest »
newest »
I think your opinion is out of context.. I don't want to use Lisp, as I'm being very well payed as a C# programmer. And this book is a must have for anyone using C#, IMO.
I wrote that review almost 10 years ago, and probably wouldn't be quite as much of a jerk about it today. And yeah, here we are in the real world where lots of people are being paid to write C#, and if you're one of them then by all means read this book.Still, big-picture wise, I at least halfway stand by what I wrote.
@Michael: wish I could like your comment too :-) Good to have follow-up discussions.I think any programmer who has dabbled in a few languages will see that Design Patterns are everywhere. Especially in functional programming, such as the ones you have in Lisp. The book "A Little Java, A Few Patterns" will show you have his Java examples gradually turn the Visitor pattern into something that is very functional in nature.
I completely agree that Java, C#, etc add a lot of ceremonial fluff, and having an AbstractStrategyFactory might be a bit over-the-top, but Design Patterns - named or not - are used everywhere, every day. I see the Factory pattern used every time I program Elm or use Redux in Javascript, returning higher-ordered curried functions that create new functions.
Know any decent game engines written in Lisp?
Reading something like Design Patterns in Ruby (a better book IMHO) makes you see how a lot if these patterns are superfluous or look totally different in a dynamic language. Which still doesn't make the topic useless. It's useful to know whether your design involved templating, factories and strategies even if you might not have proper classes for them.
Patterns are in that respect as obsolete as good program design is.