Defer identification of state variables pattern
m (Reverted edits by Ebybymic (Talk); changed back to last version by Jenny Harlow) |
|||
| (10 intermediate revisions by 8 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | [[image: defer identification of state variables 1.jpg|frame|Fig.1 A basic abstract shape class]] | |
| + | [[image: defer identification of state variables 2.jpg|thumb|Fig.2 Defer identification of state variables pattern hard at work]] | ||
| − | + | This axiom is contained in [[PLoP 1995|Pattern Languages of Program Design]] and republished in [[Ken Auer 1995]]. | |
| − | [[ | + | Also known as the [[Intelligent children pattern]] the process of deferring identification of state variables is used so the creation of variables can be postponed until the creation of subclasses further down the hierarchy. This helps make the definition of abstraction more adaptive to change and allows the creation of a class hierarchy that is less constrained by the consequences of design decisions. Every implementation detail that is put into concrete form forces subclasses to accept a design decision and its corresponding space/efficiency tradeoffs. |
| + | == Example == | ||
| + | |||
| + | The deferring is achieved by creating abstract [[Getters and setters|accessors]] instead of defining data fields. This allows the creation of the data fields to happen in a classes further down the hierarchy where there is more information available to make an informed decision. | ||
| + | For example think of a class for shape which could be defined as shown in fig.1. | ||
| + | |||
| + | Now imagine that your system has need for a shape that is stored in cartesian coordinates, a shape stored in polar coordinates and a space efficient shape that has its coordinates packed into one integer. | ||
| + | If we use the ''basic abstract shape class'' then there is no benefit in using inheritance since the ''PolarCircle'' will simply have two data fields for position, one not being used. The same goes for the ''SpaceEfficientShape'' making it far from efficient. | ||
| + | If deferring is used properly then a working inheritance structure might look like the one illustrated in Fig.2. | ||
| + | |||
| + | This pattern is useful in many situations. One such situation is the [[Parallel hierarchies problem]] that sometimes appears in OO designs. The OO design below shows an example of the Parallel Inheritance Hierarchies problem. This design shows the abstract class Vehicle holding an Operator as one of it's fields. One problem with this is that a Car object might be able to have a Pilot as its Operator instead of a Driver. For the solution see the [[Parallel hierarchies problem]]. | ||
| + | |||
| + | |||
| + | [[Image:deferred state variables 1.jpg]] | ||
== See also == | == See also == | ||
| Line 10: | Line 24: | ||
* [[Parallel hierarchies problem]] | * [[Parallel hierarchies problem]] | ||
* [[Intelligent children pattern]] | * [[Intelligent children pattern]] | ||
| + | * [[Define classes by behavior, not state pattern]] | ||
| + | * [[Ken Auer]] | ||
Latest revision as of 03:08, 25 November 2010
This axiom is contained in Pattern Languages of Program Design and republished in Ken Auer 1995.
Also known as the Intelligent children pattern the process of deferring identification of state variables is used so the creation of variables can be postponed until the creation of subclasses further down the hierarchy. This helps make the definition of abstraction more adaptive to change and allows the creation of a class hierarchy that is less constrained by the consequences of design decisions. Every implementation detail that is put into concrete form forces subclasses to accept a design decision and its corresponding space/efficiency tradeoffs.
Example
The deferring is achieved by creating abstract accessors instead of defining data fields. This allows the creation of the data fields to happen in a classes further down the hierarchy where there is more information available to make an informed decision. For example think of a class for shape which could be defined as shown in fig.1.
Now imagine that your system has need for a shape that is stored in cartesian coordinates, a shape stored in polar coordinates and a space efficient shape that has its coordinates packed into one integer. If we use the basic abstract shape class then there is no benefit in using inheritance since the PolarCircle will simply have two data fields for position, one not being used. The same goes for the SpaceEfficientShape making it far from efficient. If deferring is used properly then a working inheritance structure might look like the one illustrated in Fig.2.
This pattern is useful in many situations. One such situation is the Parallel hierarchies problem that sometimes appears in OO designs. The OO design below shows an example of the Parallel Inheritance Hierarchies problem. This design shows the abstract class Vehicle holding an Operator as one of it's fields. One problem with this is that a Car object might be able to have a Pilot as its Operator instead of a Driver. For the solution see the Parallel hierarchies problem.
