Define classes by behavior, not state pattern
This 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 there public interface and responses to the messages passed via that interface. The objects interface is independent of any implementation details within the object. This independence is important to this concept otherwise known as Behavior-defined Class.
The things useful here might be moveBy, scaleBy, draw. It may be obvious at this point that a position is needed for the object, there is no need to make any further decisions about the data structure at this point. Any more design decisions about data structures can wait until it is obvious what is required. Such as the moment the subclasses Rectangle or Circle are implemented. It is not until this happens that it becomes obvious the storage requirements will be different. One may have a radius the other a height and width.
The implementation within the object is important to the extendability of the object. Each decision made on how a data structure is represented enforces 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.
