Define classes by behavior, not state pattern
m |
|||
| Line 1: | Line 1: | ||
| − | 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]] | + | 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 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.[[Image:SimpleShape.jpg|frame]] | |
| − | The | + | 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 identification of state variables pattern|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. | 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. | ||
Revision as of 23:38, 1 September 2009
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 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.
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.
