Implement behavior with abstract state pattern
m (Reverted edits by Ebybymic (Talk); changed back to last version by Jenny Harlow) |
|||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | Defining the behaviour of a class without defining any of the data structure makes your class very flexible. By delaying the specification of implementation details we make class hierarchies that are more extensible. This allows us to follow the [[Once and only once]] principle, and allows | + | This axiom is contained in [[PLoP 1995|Pattern Languages of Program Design]] and republished in [[Ken Auer 1995]]. |
| + | |||
| + | Defining the behaviour of a class without defining any of the data structure makes your class very flexible. By delaying the specification of implementation details we make class hierarchies that are more extensible. This allows us to follow the [[Once and only once]] principle, and allows subclasses to adapt to changing space and efficiency requirements. | ||
| + | |||
| + | ====The Problem==== | ||
| + | |||
| + | Auer wrote:<blockquote>"How do we approach implementation without forcing data structure design structure on subclasses? If portions of the data structure (such as instance variables) are defined as soon as the need for a particular state is identified, there may be an abundance of state variables that may not be necessary, as they can be derived from other state variables (for example, a Circle's diameter can be derived from radius). Additionally, each detail introduced into the data structure reduces the flexibility of the subclass implementations."[[Ken Auer 1995]]</blockquote> | ||
| + | |||
| + | ====Solution==== | ||
| + | Auer said: "If implied state information is needed in order to complete the implementation details of behavior, identify the state by defining a message theat returns that state instead of defining a variable" [Ken Auer 1995]. | ||
====What to do==== | ====What to do==== | ||
| Line 6: | Line 15: | ||
== See also == | == See also == | ||
| − | * [[Ken Auer | + | * [[Avoid concrete base classes]] |
| + | * [[Ken Auer]] | ||
Latest revision as of 03:10, 25 November 2010
This axiom is contained in Pattern Languages of Program Design and republished in Ken Auer 1995.
Defining the behaviour of a class without defining any of the data structure makes your class very flexible. By delaying the specification of implementation details we make class hierarchies that are more extensible. This allows us to follow the Once and only once principle, and allows subclasses to adapt to changing space and efficiency requirements.
Contents |
The Problem
Auer wrote:"How do we approach implementation without forcing data structure design structure on subclasses? If portions of the data structure (such as instance variables) are defined as soon as the need for a particular state is identified, there may be an abundance of state variables that may not be necessary, as they can be derived from other state variables (for example, a Circle's diameter can be derived from radius). Additionally, each detail introduced into the data structure reduces the flexibility of the subclass implementations."Ken Auer 1995
Solution
Auer said: "If implied state information is needed in order to complete the implementation details of behavior, identify the state by defining a message theat returns that state instead of defining a variable" [Ken Auer 1995].
What to do
When you are defining your base class, implement all the functionality that the public interface requires. Every time you find that you require some data from the class define an abstract accessor method instead of an instance variable. Later, a class that extends your base class can fill in all the details of the data structure and the accessor methods. This makes your class very flexible to accommodate new special cases and variations.
