Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Multimorphic objects

IP.com Disclosure Number: IPCOM000131709D
Original Publication Date: 2005-Nov-16
Included in the Prior Art Database: 2005-Nov-16
Document File: 2 page(s) / 55K

Publishing Venue

IBM

Abstract

Disclosed is a mechanism to allow the hiding of operations based on the state of an object in an Object Oriented programming environment. This mechanism completely hides the operation a class can offer as the state changes allowing the object to apparently change shape. This mechanism simplifies the creation of stateful objects and makes such objects more robust. This improves the safety of control systems.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 2

Multimorphic objects

Disclosed is a system that prevents the incorrect calling of an operation on an object based upon the state of an object. Currently in OO an operation can be declared to be private but this does not prevent the object which owns the operation from calling it. An operation can contain logic to alter it's behaviour based on the runtime state but, this can require careful coding to avoid real time conflicts. Finally an object can be polymorphic but this places the onus of calling the operation with the correct parameters on the calling object, this is the same as just calling the correct operation in the first place.

    The mechanism disclosed herein allows objects to completely hide their operations, even from themselves. This requires three additions to any OO language. These additions are:
1. An operation qualifier that marks the initial state of an operation as unavailable.
2. A construct that allows the developer to create a tabulated list of the operations that become available or unavailable based on a state indicator.
3. An operation that allows for the hiding of operations in a programmatic way. This would be overridden by the tabulated list in 2.

    This mechanism will allow developers of classes to 'change the shape' of a class at runtime based on the state or logic of the class. This will prevent the calling of inappropriate methods if the object is used by any other object. The benefits will be more robust objects. For example in control systems the possibility of an incorrect operation being called would be completely prevented. This is better than using the exception system where the problem would be identified only after impossible demands have been made.

This will also make systems safer, if a reactor system was in the shut-down state the removeRods operation would not even be available!

    This could work in the following way using possible extensions to the Java* language as examples. Note that these are only examples of a possible implementation to...