design-patterns-in-ruby: Russ Olsen's Book Examples as a Runnable Repository

What design-patterns-in-ruby actually is

This repository is the example code for Design Patterns in Ruby by Russ Olsen, kept as a set of top-level directories named after each pattern: abstract_factory, adapter, builder, commands, composite, decorator, factory, interpreter, iterator, mediator, observer, proxy, singleton, strategy and template_method. The README states the book covers 14 of the original 23 GoF patterns, and the directory list matches that scope. There is no gem, no library entry point and no published release. If you are looking for a dependency to add to a Gemfile, this is the wrong shape of project. If you are reading the book and want the code next to your editor, it is exactly the right shape. The README opens with a plain maintenance signal: the code is "Updated to work with ruby 2.2.0", and contributions are invited through issues or pull requests. The last push to the repository was on 2026-05-13. The repository is not archived.

The five points the README treats as the real lesson

The pattern directories are the visible part, but the README leads with five points that apply across all of them: separate what changes from what stays the same, program to an interface rather than an implementation, prefer composition over inheritance, delegate to the class whose domain the work belongs to, and Russ Olsen's addition, you ain't gonna need it. That last point is the one worth pausing on, because it argues against the speculative flexibility that pattern catalogues often encourage. The README's own gloss is that you should not implement features or design in flexibility you do not immediately need, because you will probably never need it. Read together with the other four, this frames the examples as a vocabulary for naming structures you already have, not a checklist to apply up front. The repository does not enforce any of this. Nothing in the layout stops you from copying a Singleton example into a codebase where a plain module would do.

How the examples are organised and what each pattern contributes

Each pattern gets a directory and a README section. The sections are uneven in depth, and the unevenness is informative. Template Method gets two steps and one stated disadvantage: no runtime flexibility. Strategy is described as delegating to encapsulated algorithms that are interchangeable at runtime, and the README notes two ways to pass data from the context to the strategy, either as call parameters or as the context object itself, plus the option of using code blocks with block.call when a strategy has only one method. Observer is the longest section, and it is the one that reads like engineering notes rather than a definition. It points at the Observable module in the Ruby Standard Library, then raises three concerns the standard module does not settle: push versus pull notification, atomic event notifications when several dependent attributes are updated in sequence, and what should happen when an observer raises an exception. The README gives an example of the inconsistent-state hazard directly, showing a salary assignment followed by a title assignment with a comment marking the window where the object is inconsistent. That kind of caveat is the most valuable content in the repository, and it is concentrated in a few sections rather than spread evenly.

Cloning it and running a first example

There is nothing to install. The README gives no install steps because there is no package to install; the repository is a set of Ruby files you clone and run with whatever Ruby you have. Clone it and look at the directory layout first.

git clone https://github.com/design-patterns-in-ruby/design-patterns-in-ruby.git
cd design-patterns-in-ruby
ls

The listing should show the pattern directories plus LICENSE and README.md. Pick one pattern and read its directory before running anything, since the files are written to be read alongside the book chapter rather than executed as a suite. To try the internal iterator example the README gives verbatim, run it as a one-liner or drop it into a scratch file.

colors = ['red', 'green', 'blue']
colors.each { |color| puts color }

That prints red, green and blue, one per line. It is a demonstration of the internal iterator style, where the aggregate owns the loop and your block supplies the body. The README contrasts this with an external iterator, where the iteration logic lives in a separate class and you control which elements are visited and in what order. If a file fails to parse, the likely cause is the Ruby version: the README's update note names 2.2.0, and the repository carries no test suite or CI configuration that would tell you which versions still pass.

Where the examples are deliberately wrong

The Composite section is the clearest case of the repository documenting a weakness on purpose. The README says the implementation in the book is inflexible: tasks cannot be created dynamically, and a task cannot be split into subtasks without changing the class of the leaf Task to a CompositeTask before children can be added. The suggested fix is a single Node class used for both leaves and internal nodes, so a leaf can accept children without a class change. That is a design critique attached to a working example, and it is the pattern to look for elsewhere in the repository. The practical consequence is that you should not copy the Composite directory into production as-is. Read it to understand the structure, then follow the README's own suggestion if you need dynamic trees. The Observer section carries a comparable warning about notifying observers mid-update, and it leaves the exception-handling question open, saying the correct approach varies by case. Open questions are honest, but they mean the repository will not answer them for you.

How it compares with the Ruby standard library and with POODR

Two alternatives come up naturally. The first is Ruby's own standard library: the README points at the Observable module for the observer pattern, and at Enumerable for iteration, which means several of the patterns here already have a maintained implementation shipped with the language. The difference in approach is that the standard library gives you a working module and hides the mechanism, while this repository shows the mechanism and expects you to read it. If you want the observer pattern in a real application, the standard library module is the shorter path; if you want to understand what the module is doing, the repository's Observer directory and its push-versus-pull discussion are the material. The second alternative is Practical Object-Oriented Design in Ruby by Sandi Metz, which appears in the related searches for this project. That book teaches object-oriented design through refactoring and dependency management rather than through a named-pattern catalogue, so it covers different ground: it will not give you a directory per GoF pattern, and this repository will not teach you how to reduce coupling in an existing class hierarchy. Choosing between them is a question of whether you want a pattern vocabulary or a design process.

Licence, maintenance and what upgrading costs you

The repository is licensed CC0-1.0, which places the work in the public domain to the extent the licence permits. For a repository of book examples that is a permissive choice: you can copy a snippet into your own code without an attribution requirement. It also means there is no warranty of any kind attached to the code, and no maintainer obligation to fix anything. The README does invite issues and pull requests, and the last push was on 2026-05-13, so the repository is not abandoned. But there are no releases to upgrade between, no changelog and no version tags, so "upgrading" here means pulling the latest commit and re-reading whatever changed. The README's version note stops at Ruby 2.2.0, and nothing in the repository describes testing against later Ruby versions. Treat the code as reference material that may need small edits, not as a dependency with a support contract. This is a description of the licence and the repository state, not legal advice.

Editorial conclusion

Adopt this repository as a reading companion if you are working through Russ Olsen's book or teaching the 14 GoF patterns it covers, and clone it rather than adding it to a Gemfile. Skip it if you want a maintained library to depend on: it ships no gem, no versioned releases and no test suite, and the README's own update note stops at Ruby 2.2.0. Before relying on any example, check that the file you need still parses under your installed Ruby and read the README's stated disadvantages for that pattern, such as the Template Method's lack of runtime flexibility and the Composite implementation's inability to add children to a leaf Task without changing its class.

Frequently asked questions

Official sources

1. design-patterns-in-ruby/design-patterns-in-ruby on GitHub
2. Issues
3. License: CC0-1.0
4. README