Navigating a generalization

The path from a subclass to a superclass instance is straightforward. Let’s take R38 from the Elevator Case Study where a Bank Level is subclassed into a Top, Middle and Bottom Level. We also have R29 between the superclass and the Bank class. Now consider an action within an instance of one of the subclasses, Middle Level let’s say, where we want to find the related Bank instance, via the superclass.

myBank .= /R38/Bank Level/R29/Bank

Going the other direction, from a superclass instance downward, we need to ascertain the subclass instantiation. To do this we first perform a test and then continue navigation. In the case study example below, a method on the Bank Level superclass clears an up, down or up/down request based on its subclass.

R38? {
    _Top Bank Level:
        // If this is a top level and down is requested, clear the down request
        // set/unset are type specific operators defined on the Boolean type
        (^dir == _down)? /R38/Top Bank Level.Calling down.unset()
    _Bottom Bank Level:
        // If this is a bottom level and up is requested, clear the up request
        (^dir == _up)? /R38/Bottom Bank Level.Calling up.unset()
    .Middle Bank Level:
        ^dir? {
            // If this is a middle level and up is requested, clear up
            // If this is a middle level and down is requested, clear up
            _up: /R38/Middle Bank Level.Calling up.unset()
            _down: /R38/Middle Bank Level.Calling down.unset()
        }
}

When we test a relationship name, the result is an automatically generated enumeration value corresponding to one of the subclass names. So we can use a standard case statement to split out the possible navigation paths.

For more about the case action itself, see the relevant section under Control Flow.