Practical Object-Oriented Design in Ruby: An Agile Primer

by Sandi Metz

The foundation of an object-oriented system is the message, but the most visible organizational structure is the class.

Code should be • Transparent The consequences of change should be obvious in the code that is changing

Another way to hone in on what a class is actually doing is to attempt to describe it in one sentence. Remember that a class should do the smallest possible useful thing.

Separating iteration from the action that’s being performed on each element is a common case of multiple responsibility that is easy to recognize.

If a bit of code inside a method needs a comment, extract that bit into a separate method. The new method name serves the same purpose as did the old comment.

Your design challenge is to manage dependencies so that each class has the fewest possible; a class should know just enough to do its job and not one thing more.

If your defaults are more than simple numbers or strings, implement a defaults method.

Concrete code is easy to understand but costly to extend. Abstract code may initially seem more obscure but, once understood, is far easier to change.

The general rule for refactoring into a new inheritance hierarchy is to arrange code so that you can promote abstractions rather than demote concretions.

Composition describes a has-a relationship. Meals have appetizers, universities have departments, bicycles have parts. Meals, universities, and bicycles are composed objects. Appetizers, departments, and parts are roles. The composed object depends on the interface of the role.

Use Inheritance for is-a Relationships

Use Duck Types for behaves-like-a Relationships

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves the internal structure.

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.

The rules-of-thumb for testing private methods are thus: Never write them, and if you do, never ever test them, unless of course it makes sense to do so. Therefore, be biased against writing these tests but do not fear to do so if this would improve your lot.

The Liskov Substitution Principle declares that subtypes should be substitutable for their supertypes. Violations of Liskov result in unreliable objects that don’t behave as expected.