Rearrange Classes and Operations
Sometimes, the similar operation is defined across different classes and can easily be inherited from a familiar ancestor, but more often operations in several classes are similar, but not the same. By slightly altering the definitions of operations or classes, the operations could often be made to match so that they could be covered by a single inherited operation. The following types of adjustments can be made to increase chance of inheritance:
- We will find that some operations can have fewer arguments than others. The missing arguments can be added but normally ignored. Such as, a draw operation on a monochromatic display does not require a colour parameter, but parameter can be accepted and ignored for uniformity with colour displays.
- Some operations can have fewer arguments since they are special cases of more common arguments. In this case, you can implement special operations by calling general operation with appropriate parameter values. Such as, appending an element to list is a special case of inserting an element; here the insert point just follows the last element.
- Same attributes in different classes can have different names. Give attributes the same name and move them to a common ancestor class, then operations that access attributes will match better. Also, watch for same operations with different names. You should note that a reliable naming strategy is significant to avoid hiding similarities.
- An operation can be defined on many different classes in a group, but be undefined on other classes. Define it on a common ancestor class and declare it as a no-op on classes which do not care about it. For instance, in OMTool the begin-edit operation places some figures, for example class boxes, in a special draw mode to authorize rapid resizing while the text in them is being edited. Other figures do not have special draw mode, so begin-edit operation on these classes has no effect.