Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))

Loosely speaking, we use the message-passing style we’ve just described between objects, but we tend to use a more functional style within an object, building up behavior from methods and values that have no side effects.

Never write new functionality without a failing test.

Our purpose, in the end, is to achieve more with less code. We aspire to raise ourselves from programming in terms of control flow and data manipulation, to composing programs from smaller programs—where objects form the smallest unit of behavior.

One of the symptoms of an unstable development environment is that there’s no obvious first place to look when something fails.

an interface describes whether two components will fit together, while a protocol describes whether they will work together.

The API of a composite object should not be more complicated than that of any of its components.

As John Gall wrote in [Gall03], “A complex system that works is invariably found to have evolved from a simple system that works.”

we should be able to describe what an object does without using any conjunctions (“and,” “or”). If we find ourselves adding clauses to the description, then the object probably should be broken up into collaborating objects, usually one for each clause.

We value code that is easy to maintain over code that is easy to write.1 Implementing a feature in the most direct way can damage the maintainability of the system, for example by making the code difficult to understand or by introducing hidden dependencies between components.