Define classes by behavior, not state pattern

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m
 
(4 intermediate revisions by 3 users not shown)
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]] 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.
+
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.
  
Think for example of a simple ''Shape'' object for a graphical program.[[Image:SimpleShape.jpg|frame]]
+
Consider an example of a simple ''Shape'' object for a graphical program.[[Image:SimpleShape.jpg|frame]]
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 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]].
 
+
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 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.
SimpleShape.jpg

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.

See also

Personal tools