Design to Interfaces

Behavior in object-oriented systems is a reflection of the interaction of objects. If you change the objects or alter their interactions, the resulting behavior changes.

This means that objects have relationships to other objects, usually through references that are used to call methods. The GoF recommends that these relationships are defined based on how the objects look to each other, not by how the objects are implemented.

It's easy to misinterpret this to mean “every object should have a separate interface,” referring to the type “interface” that many languages provide. But the advice was not meant to indicate any language-specific idiom.

An “interface” means any defined means of communication. A method signature is an interface; the collective public methods of a class are an interface; an abstract class is an interface; etc. What is meant by that is the interface of any interaction should be based on what is needed by the clients and not the way the behavior is implemented. Changing the implementation should not affect the interface, and thus should not affect the clients.

In other words, the full version of this is “design to interfaces (how you work with them) rather than implementations (what each actually does).”