We ended the previous chapter by creating two new classes: a Thing and a Treasure. Despite the fact that these two classes shared some features (notably both had a “name”), there was no connection between them.

These two classes are so trivial that this tiny bit of repetition doesn’t really matter much. However, when you start writing real programs of some complexity, your classes will frequently contain numerous variables and methods, and you really don’t want to keep coding the same things over and over again.

It makes sense to create a class hierarchy in which one class may be a “special type” of some other (ancestor) class, in which case it will automatically inherit the features of its ancestor. In our simple adventure game, for instance, a Treasure is a special type of Thing, so the Treasure class should inherit the features of the Thing class.

The behavior of Things in general will be coded in the Thing class. The Treasure class will automatically “inherit” all the features of the Thing class, so we won’t need to code them all over again; it will then add some additional features, specific to Treasures.

As a general rule, when creating a class hierarchy, the classes with the most generalized behavior are higher up the hierarchy than classes with more specialist behavior. So, a Thing class with just a name and a description would be the ancestor of a Treasure class that has a name, a description, and, additionally, a value; the Thing class might also be the ancestor of some other specialist class such as a Room that has a name, a description, and exits . . . and so on.

One Parent, Many Children

This diagram shows a Thing class that has a name and a description (in a Ruby program, these might be internal variables such as @name and @description plus some methods to access them). The Treasure and Room classes both descend from the Thing class, so they automatically “inherit” a name and a description. The Treasure class adds one new item, value, so it now has name, description, and value. The Room class adds exits—so it has name, description, and exits.

Let’s see how to create a descendant class in Ruby. Load the 1adventure.rb program. This starts simply enough with the definition of a Thing class, which has two instance variables, @name and @description.

1adventure.rb

class Thing
    def initialize( aName, aDescription )
      @name         = aName
      @description  = aDescription
    end

    def get_name
        return @name
    end

    def set_name( aName )
        @name = aName
    end

    def get_description
        return @description
    end

    def set_description( aDescription )
        @description = aDescription
    end
end

The @name and @description variables are assigned values in the initialize method when a new Thing object is created. Instance variables generally cannot (and should not) be directly accessed from the world outside the class itself, because of the principle of encapsulation (as explained in the previous chapter). To obtain the value of each variable, you need a get accessor method such as get_name; in order to assign a new value, you need a set accessor method such as set_name.

class Treasure < Thing
    def initialize( aName, aDescription, aValue )
        super( aName, aDescription )
        @value = aValue
    end

    def get_value
        return @value
    end

    def set_value( aValue )
        @value = aValue
    end
end

class Treasure < Thing

super( aName, aDescription )