Polymorphic Function With Embedded Behaviour

Part of the ObjectBasedProgramming pattern language. Discussion occurs on PolymorphicFunctionWithEmbeddedBehaviourDiscussion?.

Original at http://www.geocities.com/SiliconValley/Foothills/5962/pfwitheb.htm

---

Intent

Provide a strategy to implement polymorphic functions, with the lowest level of architectural complexity.

Motivation

The PolymorphFunction? pattern requires a single polymorphic function to implement a particular operation for all subclasses in the class family. This function would need to exhibit different behaviour for objects of different subclasses if the operation is overridden by the subclasses. This pattern provides a strategy to implement polymorphic functions with the minimal architectural complexity.

Applicability

Applicability should be decided on an operation by operation basis. Some operations in a class family may benefit from this pattern while other would not. The Function Pointer pattern is applicable to an operation if:

• The operation is not intended to be overridden by the subclasses

• OR The operation can be overridden by the subclass, but the number of subclasses is small and the class family is not likely to grow.

Solution

The polymorphic function would identify the class of the instance it is operating on, and exhibit the behaviour required for the particular class. The implementation is directly hard-coded to deal with each of the recognised sub-classes.

Consequences

The PolymorphicFunctionWithEmbeddedBehaviour pattern has the following important consequences:

1. Not easily extensible. When a subclass is added to the class family, the polymorphic functions implementing the operations need to be modified to recognise the new subclass. Maintainability is reduced.

2. Less conceptual complexity. The implementation is conceptually easier to understand.

3. ClassTag pattern must be applied. The ClassTag pattern is required to provide class identification information at run-time.

Sample Code

Consider the following class family.

[1]

The setState operation is supported by two subclass Leaf alarm and Simple condition. The polymorphic function ConditionFamilySetState? implements the setState operation. A sample implementation of ConditionFamilySetState? with this pattern applied is shown below. The ClassTag pattern is also applied to provide class identification information.

void ConditionFamilySetState?( void *pvInstanceData, param1, ... ) 
{ 
int nClassTag;

/* Get the class type - class tag is stored at the beginning of the 

instance data structure */ 
nClassTag = pvInstanceData->nClassTag; 

/* Exhibit different behaviour for different subclasses */ 
switch ( nClassTag ) 
{ 
case CONDITION_TYPE_LEAF_ALARM: 
Do things to the leaf alarm instance 
break; 
case CONDITION_TYPE_SIMPLE_CONDITION: 
Do things to the simple condition instance 
break; 
case CONDITION_TYPE_ALARM: /* Fallthrough */ 
case CONDITION_TYPE_CONDITION_ALARM: /* Fallthrough */ 
case CONDITION_TYPE_NON_LEAF_ALARM: /* Fallthrough */ 
Error handling - these classes do not support this operation 
break; 
default: 
Error handling - this subclass is not supported 
break; 
} 
} 

Known Uses

This section is to be filled in.

Related Patterns

This pattern provides an implementation strategy to implement polymorphic functions described the PolymorphicFunction pattern.

The FunctionPointer pattern describes an contrasting strategy to implement polymorphic functions.

The ClassTag pattern is required as a pre-requisite of this pattern. The ClassTag pattern provides the mechanism to identify the class of an object at run-time.