Define classes by behavior, not state pattern
Jenny Harlow (Talk | contribs) m |
|||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | This axiom | + | This axiom is contained in [[PLoP 1995|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.[[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. | ||
| Line 14: | Line 13: | ||
* [[Defer identification of state variables pattern]] | * [[Defer identification of state variables pattern]] | ||
* [[Intelligent children pattern]] | * [[Intelligent children pattern]] | ||
| + | * [[Ken Auer]] | ||
Latest revision as of 07:50, 18 October 2010
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.
