Driving an interface from its client avoids leaking excess information about its implementers, which minimizes any implicit coupling between objects

Break up an object if it becomes too large to test easily, or if its test failures become difficult to interpret. Then unit-test the new parts separately.

Never write new functionality without a failing test.

We try to think about objects in terms of roles, responsibilities, and collaborators, as best described by Wirfs-Brock and McKean in [Wirfs-Brock03]. An object is an implementation of one or more roles; a role is a set of related responsibilities; and a responsibility is an obligation to perform a task or know information. A collaboration is an int

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

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

Objects can break encapsulation by sharing references to mutable objects, an effect known as aliasing.

Our response is to organize the code into two layers: an implementation layer which is the graph of objects, its behavior is the combined result of how its objects respond to events; and, a declarative layer which builds up the objects in the implementation layer, using small “sugar” methods and syntax to describe the purpose of each fragment. The

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