What I took from Design Patterns in Ruby
I read “Design Patterns in Ruby” recently. It walks through the classic Gang of Four patterns but written the way you would actually write them in Ruby, not Java translated word for word. I also leaned on a nice summary by davidgf while reading.
I am not going to list all the patterns. Half of them I will forget the names of by next month anyway. What stuck with me were a few guiding ideas that sit underneath all of them.
The ideas underneath
Separate what changes from what stays the same. Most of these patterns exist to put a wall between the part of your code that keeps changing and the part that does not. Find the thing that varies, isolate it, and the rest of the code stops caring about it.
Program to an interface, not an implementation. Depend on what an object can do, not on what class it is. This makes it easier to swap one thing for another later without rewriting everything around it.
Prefer composition over inheritance. Instead of building tall inheritance trees, give an object the pieces it needs by handing them to it. I had heard this before but the book made it click why: inheritance ties you down hard, composition leaves you free to rearrange.
Delegate. When an object gets asked to do something that is not really its job, hand it off to another object that owns that job. Keep responsibilities where they belong.
You ain’t gonna need it (YAGNI). Do not build the flexible, future-proof version until you actually have the future problem. Most of the time the future you imagined never arrives.
My main takeaway
The thing I keep coming back to is this: patterns are tools, not goals.
When you first learn patterns there is a strong temptation to use them. You see a factory-shaped hole everywhere. You wrap things in strategies that have exactly one strategy. I have done this. It feels smart and it makes the code worse.
The book made me more careful. Only reach for a pattern when you have the actual problem it solves, right now, in front of you. If you apply it because it might be useful one day, you have just over-engineered the thing and added indirection nobody asked for. That ties back to YAGNI.
The Ruby part
The book also points out things Ruby gives you that change how some patterns look, or make them unnecessary.
You can build small DSLs (domain specific languages) because the syntax is flexible enough to read almost like configuration. Metaprogramming lets objects define methods on the fly, so some patterns that exist to work around rigid languages just melt away. And convention over configuration, which Rails leans on heavily, removes a lot of the wiring that other languages need patterns for.
So a few patterns from the Java world feel like solutions to problems Ruby does not have.
Overall a good read. Not because I will recite the patterns, but because it made me ask “do I actually need this?” before adding structure. That question alone was worth it.