Practical Object-Oriented Design: An Agile Primer Using Ruby

by Metz Sandi

Use Duck Types for behaves-like-a Relationships

Use Composition for has-a Relationships

This is-a versus has-a distinction is at the core of deciding between inheritance and composition.

These techniques are tools, nothing more, and you’ll become a better designer if you practice each of them. Learning to use them properly is a matter of experience and judgment, and one of the best ways to gain experience is to learn from your own mistakes. The key to improving your design skills is to attempt these techniques, accept your errors cheerfully, remain detached from past design decisions, and refactor mercilessly.

Writing changeable code is an art whose practice relies on three different skills.

First, you must understand object-oriented design.

Good design preserves maximum flexibility at minimum cost by putting off decisions at every opportunity, deferring commitments until more specific requirements arrive.

Second, you must be skilled at refactoring code.

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.

Finally, the art of writing changeable code requires the ability to write high-value tests.

Well-designed code is easy to change, refactoring is how you change from one design to the next, and tests free you to refactor with impunity.

It is common for programmers who are new to testing to find themselves in the unhappy state where the tests they write do cost more than the value those tests provide and who therefore want to argue about the worth of tests.

Knowing Your Intentions

Finding Bugs

Supplying Documentation

Deferring Design Decisions

Supporting Abstractions

Exposing Design Flaws

Tests are the canary in the coal mine; when the design is bad, testing is hard.

Most programmers write too many tests.

Here, then, are the guidelines for what to test: 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.

It is an unfortunate truth that the most complex code is usually written by the least qualified person.

The overcomplicated applications these novices produce should be viewed as triumphs of perseverance; it’s a miracle these applications work at all. The code is hard.

Deleting Unused Interfaces

It’s not really incoming at all, it’s a speculative implementation that reeks of guessing about the future and clearly anticipates requirements that do not exist.

The goal of this section was to prove public interfaces by testing incoming messages. Wheel was cheap to test. The original Gear test was more expensive because it depended on a hidden coupling to Wheel. Replacing that coupling with an injected dependency on Diameterizable isolated the object under test but created a dilemma about whether to inject a real or a fake object.

The rules of thumb for testing private methods are: 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.

Now that you know how to write reusable tests that prove an object correctly plays a role, you can use this technique to reduce the brittleness caused by stubbing.

When you treat test doubles as you would any other role player and test them to prove their correctness, you avoid test brittleness and can stub without fear of consequence.