Practical Object-Oriented Design in Ruby

Change is unavoidable. It is ubiquitous, omnipresent, and inevitable.

Sandi Metz, Practical Object-Oriented Design. My favourite quote of all time.

What it’s about

Sandi Metz’s book (usually shortened to POODR) teaches object-oriented design through one evolving Ruby example about bicycles. It covers single responsibility, managing dependencies, flexible interfaces, duck typing, inheritance versus composition, and how to write tests that are cheap to keep. Its argument is pragmatic: design isn’t about getting it right up front, it’s about keeping tomorrow’s change cheap.

What I learned

Design exists to reduce the cost of change. Not to be elegant, not to follow a pattern. If a design makes the next change harder, it’s a bad design, however clever it looks.

Depend on things that change less often than you do. Every dependency is a bet that the other thing won’t change under you. Point dependencies at the stable parts.

Think in messages, not objects. Start by asking what one part needs to ask another, then design the interface around that message. The objects follow.

Duck typing and composition beat deep hierarchies. If several things can respond to the same message, the caller shouldn’t care what they are.

What I applied

Ruby was my first real language. As a teenager I took The Iron Yard’s Ruby on Rails course and then went back as a volunteer, helping run one-day beginner Ruby courses. My A-level coursework was a Ruby on Rails platform to help teachers, with modules for lesson planning and, the part I’m proudest of, a classroom seating-plan generator. You drew out the classroom, then it filled the seats according to each student’s needs, with rules for real needs: students with poor eyesight near the front, space and support for students with special educational needs, and never seating two disruptive students together.

Looking back, that generator is a lovely early example of the book’s ideas. It was constraint-based design: the layout, the students and the rules were separate things, and placing someone meant asking each rule (eyesight, special needs, behaviour) “is this seat allowed?” rather than writing one giant function that knew everything. Adding a new rule meant adding a new object that answered the same message. I didn’t have the vocabulary then. POODR gave it to me.

The ideas map straight onto my front-end work since. The graph component library I led at Sky exposed composable parts and events (onNodeSelect rather than opinions), so each product could depend on a small, stable interface (Headless Component Libraries). And when I explain React component boundaries, I still talk in messages: what does this component need to ask, and who should answer?

One line I keep coming back to

Change is unavoidable. It is ubiquitous, omnipresent, and inevitable.

It’s my favourite quote of all time, and the reason I design the way I do. If change is guaranteed, the only real question is how cheap you’ve made it. It holds just as well outside code: in teams, in training and in life.

Where it connects

SOLID React · Bulletproof React · Headless Component Libraries · Building a Graph Component Library · Refactoring · Clean Code