Defer identification of state variables pattern
| Line 1: | Line 1: | ||
| − | + | Also known as the [[Intelligent children pattern]] The process of deferring identification of state variables is used so that the creation of state 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. | |
| + | |||
| + | 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. | ||
| + | |||
| + | 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 a Car object might be able to have a Pilot as its Operator instead of a Driver. For the solution see the [[parallel hierarchies page]]. | ||
More to come soon on this page. | More to come soon on this page. | ||
Revision as of 04:21, 22 August 2008
Also known as the Intelligent children pattern The process of deferring identification of state variables is used so that the creation of state 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.
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.
This pattern is useful in many situations. One such situation is theParallel 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 a Car object might be able to have a Pilot as its Operator instead of a Driver. For the solution see the parallel hierarchies page.
More to come soon on this page.
