Define classes by behavior, not state pattern
This axiom is contained in Pattern Languages of Program Design and republished in Ken Auer 1995. Auer referred to it as the Behavior-Defined Class pattern.
The axiom suggests that the behavior of an object should be its defining characteristic. This idea makes more sense if we extract ourselves from typed languages such as C++, C# and Java and instead delve into to the untyped world of languages like Smalltalk. In Smalltalk, objects are only defined by the methods that they have available in the public interface and any variable can hold any object. This encourages a different way of looking at things. Objects are identified by their public interface and responses to the messages passed via that interface. The object's interface is independent of any implementation details within the object. This independence is important to this concept otherwise known as Behavior-defined Class.
Consider an example of a simple Shape object for a graphical program.
The relevant operations might be moveBy, scaleBy, and draw. It may be obvious at this point that a position is needed for the object, but we don't actually have to make a decision about how we will store position at this stage. We can decide what data structure to use when the requirements are more clear. We may wait until we implement subclasses, such as Rectangle and Circle. When we implement Rectangle and Circle it becomes very clear that one has a radius the other a height and width.
How we implement the object has a great effect on the extendability of the object. Each decision made introduces certain limitations on efficiency and size. Any child of this class inherits all of these decisions and limitations. With this in mind it is best to defer the identification of state variables.
Much like Design by contract, Behavior-Defined Classes are required to fulfill their responsibilities. This implies that a minimal effective interface will serve the object and the developer best.
