Practical Object-Oriented Design in Ruby: An Agile Primer

by Sandi Metz

maintainability over the life of the code is more important than optimizing its present state.

Agile works because it acknowledges that certainty is unattainable in advance of the application’s existence; Agile’s acceptance of this truth allows it to provide strategies to overcome the handicap of developing software while knowing neither the target nor the timeline.

When the act of design prevents software from being delivered on time, you have lost. Delivering half of a well-designed application might be the same as delivering no application at all. However, if design takes half of your time this morning, pays that time back this afternoon, and then continues to provide benefits for the lifetime of the application, you get a kind of daily compounding interest on your time; this design effort pays off forever.

You will never know less than you know right now.

If the simplest description you can devise uses the word “and,” the class likely has more than one responsibility. If it uses the word “or,” then the class has more than one responsibility and they aren’t even very related.

Your application may be permanently handicapped by your reluctance to pay the price required to make a change to this class.

Depend on things that change less often than you do is a heuristic that stands in for all the ideas in this section.

When a dynamically typed application cannot be tuned to run quickly enough, static typing is the alternative. If you must, you must.

Creating code that fails with reasonable error messages takes minor effort in the present but provides value forever. Each error message is a small thing, but small things accumulate to produce big effects and it is this attention to detail that marks you as a serious programmer.

Abstract superclasses use the template method pattern to invite inheritors to supply specializations, and use hook methods to allow these inheritors to contribute these specializations without being forced to send super.

Because objects depend on everything above them, a deep hierarchy has a large set of built-in dependencies, each of which might someday change.

If testing one object drags a bunch of others into the mix, the code has too many dependencies. If the test is hard to write, other objects will find the code difficult to reuse.

Incoming messages should be tested for the state they return. Outgoing command messages should be tested to ensure they get sent. Outgoing query messages should not be tested.

You application is improved by ruthlessly eliminating code that is not actively being used.

An object with many private methods exudes the design smell of having too many responsibilities.