One dichotomy we see in the description of software components is
the separation into behavior and state.
The behavior of a component is the set of actions a component
can perform. The complete set of behavior for a component is
sometimes called the protocol.
The state of a component represents all the information
(data values) held within a component.
Normally the external description of a comonent should emphasize behavior, and downplay the state. It is considered very bad form if one object requires direct access to the state of another in order to perform its task. Instead, all actions should be mediated by behaviors.
Notice that it is common for behavior to change state. For example, the edit behavior of a recipe may change the preparation instructions, which is part of the state.