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

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.

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

The fewer methods there are on an interface, the more obvious is its role in the calling object.

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

When we notice that a group of values are always used together, we take that as a suggestion that there’s a missing construct.

When extracting implicit components, we start by looking for two conditions: arguments that are always used together in the class, and those that have the same lifetime. Once we’ve found a coincidence, we have the harder task of finding a good name that explains the concept.

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.

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