Defer identification of state variables pattern
Line 8: | Line 8: | ||
− | Now | + | 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 in no benefit to using inheritance the ''PolarCircle'' will have two data fields for position, one not being used. The same goes for the ''SpaceEfficientShape'' making it far from efficient. | If we use the ''basic abstract shape class'' then there in no benefit to using inheritance the ''PolarCircle'' will 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 | + | 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 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]]. | + | 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]]. |
Revision as of 04:49, 7 October 2008
Also known as the Intelligent children pattern the process of deferring identification of state variables is used so that 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.
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 in no benefit to using inheritance the PolarCircle will 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.
See also
This concept was originally introduced by Ken Auer in his paper Reusability through self-encapsulation.