Welcome InformIT readers! You might also like to see my review of Eloquent Ruby. Enjoy!
UPDATE: If you like this review, and want to learn more, check out interview with author, Russ Olsen.
The Professional Ruby Series from Addison-Wesley is rapidly becoming a heavyweight in Ruby book circles. I just received a complimentary copy of Russ Olsen’s Design Patterns In Ruby
from them, and it looks like a great addition to their, already solid, line-up of books.Russ breaks the book into three parts: Patterns And Ruby, Patterns In Ruby, and Patterns For Ruby. I think this is a good division and provides good coverage. Part II makes up the bulk of the book, while Parts I and III combined take up about a third the total.
I really like the first chapter of Part 1, “Building Better Programs with Patterns”. I’m less sold on the second chapter, “Getting Started with Ruby”—if you’re putting together an advanced book on Ruby, including a tutorial chapter seems a bit silly.
Part III is presents three patterns (one to a chapter) for Ruby Development: DSLs, Meta-programming, and ‘Convention over Configuration’. I think the third is more of a Railsism than a Rubyism, but it’s certainly worth considering. Also in Part III are a short conclusory chapter and two appendices. Appendix A discusses installing Ruby (again, I’m not sure why this one was included) and Appendix B provides references to further information.
Since Part II is so large, I thought I’d hit it last. Its thirteen chapters cover fourteen of the patterns presented in the Gang of Four Book
. In selecting these, Russ says he leaned toward those most useful in writing code and those that change most between the original and the Ruby implementation. The patterns covered in this book are: Template Method, Strategy, Observer, Composite, Iterator, Command, Adapter, Proxy, Decorator, Singleton, Factory Method, Abstract Factory, Builder, and Interpreter.Each of the Patterns chapters in Parts II and III feature three sections that I really liked: ‘Using and Abusing Foo’, ‘Foo in the Wild’, and ‘Wrapping Up’. In addition to be a good unifying touch, these were a great overview of each of the seventeen covered patterns I especially enjoyed the ‘Foo in the Wild’ sections making use of existing Ruby and Rails code to show the pattern in use.
All in all, Design Patterns In Ruby
is a really good book. I’m planning on spending a lot more time with it, and it looks to have a regular spot at my desk.
9 comments:
Thanks for the review. I've been programming in Ruby for a year now, and I have just started to learn about design patterns.
My work has just purchased the book by the Gang of Four. Is it easy enough to implement any pattern after reading it, or would this book save sufficient headache?
Design Patterns In Ruby doesn't include all of the patterns in the Gang of Four, but it does a better job of presenting the ruby side of the patterns that it does cover.
I hope that makes sense.
"Design Patterns In Ruby doesn't include all of the patterns in the Gang of Four, but it does a better job of presenting the ruby side of the patterns that it does cover."
Does the book include patterns that do not appear in the GoF? Are there not patterns for dynamic languages, such as Ruby, that simply do not arise in languages such as Java and C++ (the focus of the GoF book)?
James,
yes, there are three patterns (in Part III) which are not in the GoF. None of them is unique to Ruby or to dynamic languages, but they are certainly more common in that space.
Earlier, Xin wrote:
> My work has just purchased the
> book by the Gang of Four. Is it easy
> enough to implement any pattern
> after reading it, or would this book
> save sufficient headache?
Well my own two cents would be that it is a serious mistake to simply translate the patterns from the original GoF patterns into Ruby. It's not that they wouldn't work (they would) it's just that if you did so you would not be programming in Ruby - you would be writing C++ or Java in Ruby.
The patterns as implemented in Design Patterns are mostly done in C++ and the solutions are appropriate to C++ and (mostly) to Java. But Ruby has its own way of solving many of the problems attacked by the GoF pattern. One of the things that I try to do in the book is show how you would go about solving these problems the Ruby way, by taking advantage of the flexibility that Ruby provides.
Russ
Russ,
Thank you for your reply. I now know what you mean after looking into design pattern implementations in Ruby.
I look forward to reading your book.
Xin
One of the things that I liked about leaving Java was leaving the kind of nonsense that design patterns represented. Too many dweebs with nothing better to do with their time then think up ways to add needless complexity to developing systems & giving programmer-interviewers another reason to disqualify otherwise qualified developers.
This is not a good thing that someone thought it was a good idea to port this into the ruby space. Design Patterns imo are the antithesis of what Rails was about.
> Anonymous said...
>
> One of the things that I liked about
> leaving Java was leaving the kind of
> nonsense that design patterns
> represented.
Actually, I couldn't agree with
you more.
In some circles Design Patterns are
definitely part of the problem, not the
solution. But I don't think that the
problem is the the very idea of
design patterns, but rather the slavish
devotion to those original 23 patterns.
I think the idea that all 23 somehow
represent universal programming ideas
is just silly. Some are reasonably
universal, some are mired in mid
1990s C++.
When done right, a design pattern
is a little spring loaded solution
to a common program design problem.
But of course your problems and
the appropriate solutions depend
on the language you are using.
What I tried to do in the book is
explain how those old design patterns
morphed as they got to Ruby. What
is it about Ruby that makes solving
this problem different?
> Design Patterns imo are the
> antithesis of what Rails was about.
Well if you are talking about the
closed minded approach to design
patterns, again, I agree. But you
can also look at Rails as a whole
bunch of interesting solutions to
the problems of building web apps,
solutions that perhaps we should
capture for future use.
If none of that works for you,
let me just say that Obie
Fernandez - author of The Rails
Way - has been known to introduce
me to people as "This is Russ
Olsen, he wrote a book on
design patterns that DOESN'T
SUCK". I never know what to say
to that.
Russ
Glad to see a work on Design Patterns that avoids the "gotta catch 'em all" approach. Programming is not like Pokémon, thank you. Still, I wonder if the association could have been avoided by using a term other than Design Patterns.
Post a Comment