The title says it all, but how does one actually implement object oriented design patterns in Ruby? If you’re like me and always struggled with putting what you read about programming into an actual implementation and the examples in the book or around the internet weren’t enough to quell your doubts, read on.

Why do this?

Much is said about learning design patterns, specifically object oriented design patterns as described in the Design Patterns book (the Gang of Four book, as it is commonly known), in order to be a good developer. But, as I began to learn to program, one thing that always had me somewhat confused and unable to evaluate whether or not I needed to use a specific pattern, or whether I needed to use a design pattern at all, was that I had never seen an actual implementation of these patterns and, at the time, searching through repos to see where they were actually used and how they were implemented was just out of the question. I guess I’m just the type of person that needs someone to guide me through something, otherwise it takes me a very long time to understand how to translate a design pattern to its implementation.

Yes, I know that the book has example implementations with it, and I know that there are many examples throughout the internet, most notably here opens a new window . However, I intend, with these articles, to present these patterns and have a more interesting implementation at the end that is used for something more practical than having a FurnitureFactory that is implemented by ColonialFurnitureFactory and ModernFurnitureFactory.

It’s not that the examples don’t illustrate well, it’s that it’d be nice to use these patterns for something I could actually want to use. For now I’ll try to make a game, but since software development isn’t the type of thing that you want to start by over engineering solutions, maybe some patterns just won’t fit into a game, so I’ll have to come up with something more interesting.

On Design Patterns (a quick primer)

Before starting, I believe a small clarification is in order. The first question when dealing with a new piece of knowledge is to ask first “What is it?”. So, what is a design pattern? Best simply to refer to the Design Patterns book itself which, in turn, quotes “A Pattern Language”, by Cristopher Alexander et al.:

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way that you can use this solution a million times over, without ever doing it the same way twice.

With that in mind, the authors of Design Patterns compiled all of these problems with their corresponding solutions in the book and divided them into three main categories:

• Creational Patterns
• Structural Patterns
• Behavorial Patterns

Creational patterns try to solve problems related to object creation, structural patterns deal with how classes or objects are composed, and behavioral patterns characterize how classes or objects interact and distribute responsibility.

Much of our work as developers is a certain prudence on when we should use a given pattern. That means that we must be able to identify the problem we have at hand. Once we do that, we’ll be in a position to evaluate which pattern solves the problem we’re facing, and more importantly, whether it is convenient to apply the pattern at that moment of the application’s life.

Now, that decision in itself can render multiple articles, but we won’t even be able to get to the point where we’re faced with that choice unless we know well what are these common problems and the patterns that solve them. If we can’t correctly identify the problems we’re faced with, we’ll just flail about and, more often than not, implement bad solutions or just get frustrated and never solve the problem at hand.

How this will work

I intend to go through all the patterns in the Design Patterns book (for succinctness I might just refer to it as the “GoF book”), and implement them in Ruby, in the context of an application (any one will do, really) with the caveat that I want to at least try to make my examples closer to something we might actually see in the wild rather than a thought-up model to fit the pattern.

I will proceed in order. Initially, I want to make only the one application (a text based adventure game), but I’ll create others if fitting a certain pattern into it makes no sense.

The articles will first describe the problem to be solved, the solution, in terms of the design, together with the concrete implementation. And at the end I’ll discuss some caveats and provide links to the repos with the code. In other words, I’ll basically emulate the book, but with my own thoughts, Ruby code and a link to runnable code rather than just the samples in the article.

Also, since I play the piano and love classical music, and because my articles might be quite long, I might divide them into pieces. For each pattern, I’ll make an opus that might have one or more movements. It’ll make for an easier catalog and quick search in my opinion.