Data Structures and Algorithms with Object-Oriented Design Patterns in Ruby
next up previous index

Class Hierarchy

The Ruby class hierarchy which is used to represent the basic repertoire of abstract data types is shown in Figure gif. Two kinds of classes are shown in Figure gif; abstract Ruby classes , which look like this tex2html_wrap59841, and concrete Ruby classes , which look like this tex2html_wrap59843. Arrows in the figure indicate the specializes  relation between classes; an arrow points from a derived class to the base class from which it is derived.

Figure: Object class hierarchy.

The distinction between an abstract class  and a concrete class  is purely one of convention. These concepts are not built into the Ruby language. Nevertheless, it is possible to write Ruby programs in a way that makes it clear that a class is an abstract class.

An abstract class  is a class which defines only part of an implementation. Consequently, it does not make sense to create object instances of abstract classes. By convention, an abstract class may contain zero or more abstract methods . As with classes, the distinction between abstract methods and concrete methods is purely one of convention. An abstract method or property is one for which no implementation is given.

An abstract class is intended to be used as the base class  from which other classes are derived . The derived classes are expected to override  the abstract methods of the base classes. By defining abstract methods in the base class, it is possible to understand how an object of a derived class can be used. We don't need to know how a particular object instance is implemented, nor do we need to know of which derived class it is an instance.

This design pattern uses the idea of polymorphism . Polymorphism literally means ``having many forms.'' The essential idea is that a base class is used to define the set of values and the set of operations--the abstract data type. Then, various different implementations (many forms) of the abstract data type can be made. We do this by defining abstract classes that contain shared implementation features and then by deriving concrete classes from the abstract base classes.

The remainder of this section presents the top levels of the class hierarchy shown in Figure gif. The top levels define those attributes of objects which are common to all of the classes in the hierarchy. The lower levels of the hierarchy are presented in subsequent chapters where the abstractions are defined and various implementations of those abstractions are elaborated.

next up previous index

Bruno Copyright © 2004 by Bruno R. Preiss, P.Eng. All rights reserved.