Decorators Verses the Mix-in
It is a neat time to be involved in the Ruby community, if you ask me. A large portion of us are currently studying the techniques for doing good object oriented development. We are looking at the ideas that have come before and trying to decide the best ways to apply those ideas to our favorite language. This leads to blog posts, forum threads, and conference talks about what we are learning. No matter what, we all gain from explorations like this. Everybody wins as our collective knowledge grows. We all deserve gold stars.
So far, there's one point pretty much everyone agrees on: composition should typically be preferred to inheritance. The trickier part of that discussion though is deciding what composition looks like in Ruby. Generally you see Rubyists comparing the merits of decorators and mix-ins. [Note: the comments correctly pointed out that this was a bad use of the word "composition" on my part, to describe mix-ins.] There's a very representative thread on the excellent Objects on Rails mailing list.
I love studying how the human brain works. It's an amazing biological machine capable of impressive feats. Of course, it also has its quirks.
For example, the brain is a terrific pattern matcher. That's probably one of its favorite activities. It wants to do this so much that it will often even find patterns that aren't there.
While this "feature" of your brain can get you into trouble, you can also make it work for you. Some parts of programming really are about patterns. If you prime your brain with the right data, it will just take over and do one of the things it does best.
How I Teach Iterators
One evening, at a post Ruby conference dinner, Glenn Vanderburg and I had a lengthy discussion about iterators and patterns. During this discussion we nailed down a plan for how the iterators could be taught.
I know that we've both used the strategy we came up with in multiple Ruby trainings and we have both seen it work wonders. This is hands down the best way to learn the iterators, in my opinion.
Design Patterns in Ruby
I've been lucky enough to read a string of good Ruby books lately and the latest in that line is Design Patterns in Ruby. This book attempts to modernize the software design patterns by showing how these patterns can be applied in a language as dynamic as Ruby. Despite a couple of minor missteps along the way, the book definitely delivers on this goal.
Design Patterns in Ruby begins with a couple of introductory chapters introducing both the concepts behind reusable software patterns and the Ruby programming language. After that, the main section of the book has 13 chapters that walk through 14 of the patterns first introduced in the famous "Gang of Four" book that began the design patterns movement. The author then introduces three new patterns he feels have grown out of day to day Ruby usage. Finally the book closes with a short conclusion and two appendices on installing Ruby and other sources of information.
Most of that content is exactly what I wanted to find in this book, but you're going to have to tolerate a diversion about a pet peeve of mine that is strangely common in Ruby books. This is really, really important, so listen up: you can't teach Ruby in 30 pages. Period. I can hear all on the "But…" replies forming out there now… No buts. You can't. Trust me. Not even if the person is already an experienced programmer. It just can't be done. Authors and publishers need to come to terms with that and move on. Its just fine to say, "This is not a beginning Ruby book." We even prefer that, because we know when we are ready to read it and we don't have to skip that useless 30 page chapter when we do. Please, stop including introductory Ruby chapters in every book.