Operation Vapourware

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

Original at http://web.archive.org/web/20010515073521/http://www.geocities.com/SiliconValley/Foothills/5962/operationvapourware.htm.

---

Intent

Reduce the overhead to access protected object attributes.

Motivation

A well designed class protects its attributes from direct access. Access to such attributes are often channelled through operations that provide no additional functionality. Although the protection is valuable for maintainability and robustness, the additional cost of calling an operation to retrieve and set an attribute is often unjustifiable in the context of embedded software.

Applicability

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

• The operation for all known subclasses in the class family performs nothing more than a gateway to access an attribute.

• AND the operation will never be overridden in a future sub-class.

• AND the attribute accessed by the operation resides in a fixed location in the instance data for all subclasses.

• AND the attribute can be accessed as an atomic operation.

• AND it is considered acceptable to expose the structure of the instance data.

Solution

The operation is eliminated. Any call to this operation is replaced by a direct access to the attribute in the instance data.

Consequences

The OperationVapourware pattern has three important consequences:

1. Breaks encapsulation. Direct access to the attributes of an object is an violation of the encapsulation principal. The implementation of a class should be hidden from the outside world. This pattern however requires the exposure of the structure of the instance data structure. Consequently any classes which now directly access the instance data structure of the optimised class will be coupled to the implementation of the optimised class. The higher coupling compromises the reuse potential and maintainability.

2. Increased speed and reduced code size. The increased speed is a direct consequence of the elimination of the function call. Reduced code-size is likely given that, for most processors, the instruction sequence for a memory access is shorter that the instruction sequence required to push the parameters into the stack and call a function.

3. More susceptible to programmer mistake. The operation as specified in the OOD often limits read-write access to the attribute. The application of this pattern now leaves the underlying attribute open to accidental and deliberate modification. It becomes the responsibility of the interacting classes to ensure the access rights are not violated.

Sample Code

Consider the following Condition class:

- BrokenLink as of 2003-10-19

The operation getChangeCount() provides read-only access to the protected attribute ChangeCount?.

If the Operation Vapourware pattern is not applied, the operation will have the following interface:

int ConditionFamilyGetChangeCount?( void *pvInstanceData )

Another object attempting to retrieve the change count from an instance of the Condition class will implement a code fragment such as:

nChangeCount = ConditionFamilyGetChangeCount?( pvCondition )

If the Operation Vapourware pattern is applied, another object attempting to retrieve to change count from an instance of the Condition class will instead implement a code fragment such as:

nChangeCount = ( (tsCONDITION*) pvCondition )->nChangeCount; 

Known Uses

The Condition Manager in Network Management Unit Software (NUS) developed by MAS Technology applies the OperationVapourware pattern to the getChangeCount and getDescendentChangeCount operations. The example above comes from the Condition Manager.

Related Patterns

Operations that do not get eliminated by the application of this pattern should be implemented with the PolymorphicFunction pattern.