I came across this book ‘Understanding the 4 Rules of Simple Design’ by Corey Haines. It looked interesting but not enough to buy it, until I heard an excellent, more-than-an-hour-long interview of the author by the Ruby Rogues crew.

The 4 rules

What are these rules the book talks about? Authored by Kent Beck around 1999, these are guidelines, fundamental concepts of software design, to keep in mind while refactoring code, in order to develop maintainable, easy to change code that survives the trial of time. The rules are:

  1. Tests Pass
  2. Expresses Intent
  3. No Duplication (DRY)
  4. Small (Fewest elements)

Tests Pass

The proof that the system works. It doesn’t really matter if the design is great or not if I can’t be sure everything works as expected. We can think of tests, as the first consumer of our components, interacting the same way as the rest of the system.

Expresses Intent

This is about giving variables, methods, classes, etc. a good name that describes exactly what they do. One of the fundamental qualities of code, when adding new features or change behavior, is how easy is to find the part that should be changed.

No Duplication (DRY)

“Every piece of knowledge should have one and only one representation” (The pragmatic Programmer by Dave Thomas and Andy Hunt) This rule is not really about code duplication, it’s about knowledge duplication. It happens that when looking at two similar pieces of code, it’s tempting to think about extracting it into some kind of abstraction, but this is not always a good idea. Instead, we need to ask ourselves if these two pieces of code are examples of core knowledge in the system. If they are, go and extract it. If not, it’s better to leave it as two different things.

Small

Very simple: Keep the code as small as possible. Is there any legacy code no longer used? Just delete that. Are there any duplicated abstractions? Merge them into one. Went too far extracting abstractions? Remove those classes that are not really worth it.

The Book

Easy to read, well written, and short (<100 pages). At first sight, I would have guessed the author would go deeper through each of these items one at the time, but to my (pleasant) surprise, he doesn’t. Instead, he briefly describes the 4 rules, using some examples taken from Coderetreat sessions, walking the reader through the different options that arise trying to implement different parts of Conway’s Game of Life following the rules. He presents possible solutions to different problems, and how these are either in line or fail to follow the rules. The examples are written in Ruby, but those are very short and focused, and can be easily applied to any other language. After all, the book is all about software design in general.

Some key items developed in the book

  • Test Names Should Influence Object’s API
  • Don’t Have Tests Depend on Previous Tests
  • Testing State vs Testing Behavior
  • Duplication of Knowledge (DRY)
  • Naive Duplication (misunderstanding of the idea of DRY, very interesting!)
  • Behavior Attractors
  • Breaking Abstraction Level
  • Procedural Polymorphism
  • Inverted Composition as a Replacement for Inheritance

Summary

In short, the idea is that the 4 rules get along together, trying to apply one makes it simpler to apply the rest, or, while applying one it makes it clear that we are breaking another one.

As the author suggested in the first pages, I did a first Quick & dirty™ implementation of the game, and I will do some refactoring trying to follow these rules as an excercise. There are also some proposed constraints to implement it such as, components should not expose internal state or properties, and methods should not return any value. Do it yourself if you can. It’s very fun!

I strongly recommend this book to all of us ever willing to improve our software design skills. If you care about your software being easy to adapt to changing requirements and a continuously evolving environment, this book is for you.

https://leanpub.com/4rulesofsimpledesign