Class Relationships

You can create user classes to structure your organization's data into objects. These objects, with all of their characteristics and behaviors built in directly, can serve as the basis for your applications.

Before creating classes to represent your data, you must understand the two basic kinds of relationships between classes. Only after you have clearly identified a class and its relationships to other classes can you best define attributes and methods at the most general level. These kinds of relationships are:

The inheritance hierarchy inter-class relationship assumes that each class defines its own attributes and methods and inherits those defined for its superclass.

In developing an application for managing a company, you might define a superclass called Employee with two subclasses, PermanentEmployee and TempEmployee. Because every employee must be either permanent or temporary, Employee is an abstract (general) class that defines attributes common to all employees, such as LastName, FirstName, EmpNum, and HireDate. PermanentEmployee and TempEmployee are specialized classes that represent actual employees.

The PermanentEmployee and TempEmployee subclasses inherit the attributes of Employee. In addition to the Employee attributes, PermanentEmployee defines attributes specific to its class, such as InsurancePlan and NextReviewDate.

Because managers are a specific kind of permanent employee, you might define a Manager user class that is a subclass of PermanentEmployee. In addition to the attributes inherited from both of its superclasses, this class also has a BonusRate attribute.

Methods common to all staff are also defined at the top level. The Employee class, for example, defines the Hire and Terminate methods. Methods specific to a subclass are defined at the subclass level. For example, the Manager class might define a CalculateBonus method.

Examples of OpenROAD system classes that follow this relationship model are ActiveField and ButtonField. ActiveField is an abstract class that defines the characteristics and behavior of all fields with which users can interact. The ButtonField class is a subclass of ActiveField that provides an area on the form or which the user can initiate an action. Its characteristics and behavior are more specifically defined than its parents.

The aggregation inter-class relationship describes an object that is composed of separate, smaller objects that function together. The Employee and Job classes provide an example:

• The Job object contains attributes (such as Title, Class, and Pay) that describe a specific job held by a specific employee during a specified time.

• An Employee object consists not only of scalar attributes (such as LastName and HireDate) but also of a complete job history for each position the employee has filled at the company. (For a full description of this class, see How Polymorphism Works.)

The JobHistory attribute of the Employee class, which is an array of Job objects, exemplifies an aggregation relationship.

Although the data pertaining to employees is stored in several database tables and structured in different user classes, the application user who manipulates the Employee object does not think in terms of the separate objects composing the whole, but works with the aggregate as a single object. Aggregate objects allow far more complicated structures than simple objects.

An example of an OpenROAD system class that follows this relationship model is TableFields. TableFields contain such other classes as an optional scrollbar (ScrollBarField), an optional control menu (ControlButton), and an array of column fields (StackField).

Most objects participate in both types of relationships simultaneously. For example, Employee and Job are both members of an inheritance hierarchy and share an aggregation relationship.