9.2.1 Objects and Literals

The concept of an object is fundamental in the OO model. An object corresponds to an entity in our previous terminology but has both a state and a behavior. The state includes the internal structure of the object, its descriptive attributes or data elements, and the relationships it participates in with other objects. The behavior is the set of methods (functions or procedures) that can be performed on it. These include methods to create, access, and manipulate the object. Each method has a signature, giving its name and the number, order, and types of its parameters. Objects are encapsulated, which means that their data and methods form a unit and that access to the data is restricted. Only the object’s own methods, usually created and programmed by the designer of the object, are permitted to access the data, protecting it from changes by outside code. The external appearance of an object, visible to the outside world, is called its interface, and it consists of a description of the object’s state and the signatures of its methods. The outside world interacts with the object through its interface, calling the object’s own methods to perform any operations on its data elements.

FIGURE 9.1 illustrates two objects of a class called Person. Each Person object instance has its own identifier (firstPerson and secondPerson, in this example) and attributes ID, name, address, and phone, with its own values for those attributes. Each object is encapsulated, and the values of its attributes are accessible to the outside world only through its methods, such as getName() and setName(). The arrows to and from these methods in Figure 9.1 show that all communication is through the methods. From the names of these methods, we can assume that the programmer who designed these objects has written code for a function or procedure that returns the value of the name attribute (getName()) and one that allows the user to provide a new value for the name attribute (setName()). To make the other attributes accessible, the programmer who designed these objects should add get and set methods for them, as well as for any other operations that should be defined for Person objects.

A literal differs from an object in that it has a state (value) but no object identifier (OID). Atomic literals are the values of the basic built-in types, but structured literals can also be defined.

In addition to the fundamental data types, OO systems support user-defined data types (UDTs); structured types such as records; collection types such as arrays, sets, and others; and reference types, which are similar to pointers in programming languages. New types can be created incorporating previously defined types.

9.2.2 Classes

A class is a description or template of objects having the same structure, including the same attributes with the same data types, and the same methods and relationships. A class is roughly equivalent to an entity type, except that it includes operations and relationships, not just data elements. Classes are defined by listing their components, which consist of data members (attributes, instance variables), the relationships that the objects in the class participate in, and member methods (functions or procedures that belong to the class). The general form we will use for a class definition is

For example, we can define a Person class as

In this class definition, the four attributes are identified by their names and data types, and two methods are listed.

We use the class to create a Person object within the user program, with a statement such as

or

This type of statement invokes a constructor, a build-in method that creates new objects of the class. The constructor always has the same name as the class. In this case, Person is the constructor that creates new Person objects, such as firstPerson.

The method setName() in the Person class definition has a single input string parameter, newName, but it has no return value, as indicated by void. As the name of the method implies, it is intended to set the value of an object’s name attribute. A method such as this one that inserts or updates the value of a data member is called a mutator method. The code for a method is normally written by the designer of the class. The setName() method might be defined as follows

The method is called from a user program to set the name of a Person object. The user is not able to assign the person’s name by referring directly to the name attribute of firstPerson because of encapsulation of objects. Instead, the user program should contain a command such as

Here, firstPerson is the calling object, which is the object used to call the method, and it becomes the implicit parameter for the method. Within the method, it is referred to as the self (or this) parameter. We referred to the parameter by name in the assignment line of the method

The getName() method is an example of an observer method, one that returns the value of a data member. The code written by the designer of the class might be

Within the user program, we call this method using an object as the implicit parameter. If we write

the firstPerson object is the implicit parameter for the method, and the name attribute of that object is returned, resulting in the value Jack Spratt being assigned to the user program variable employeeName.

Methods may be overloaded, which means the same method name may be used for different classes and will have different code for them. Two methods for the same class may also have the same name, but if their signatures are different, they are considered different methods.

The set of objects belonging to a class is called the extent of the class. An entity set is roughly equivalent to a class extent. The data types for the attributes of a class can be predefined atomic types including integer, real, character, Boolean, and more complex types as well as user-defined types. The individual objects in the class are called instances, object instances, or simply objects, and they are similar to entity instances.

9.2.3 Class Hierarchies and Inheritance

Classes are organized into class hierarchies, which are tree-like structures. At the top is a base class, which can have any number of child classes. Each of these can in turn have any number of child classes, which in turn can have their own child classes, and so on. The parent classes are called superclasses, and the child classes are subclasses. Each subclass has an extends relationship with its superclass. We can interpret the relationship to mean an object in the subclass is an object in the superclass—“a Student is a Person,” for example. Subclasses inherit the data members, relationships, and methods of their superclasses, and they may have additional data members, relationships, and methods of their own.

FIGURE 9.2 shows an example of a simplified class hierarchy consisting of a Person class with subclasses Student and Faculty. Student, in turn, has subclasses Undergraduate and Graduate. There is also a TeachingAssistant class, which we will discuss later in this section.

FIGURE 9.3 shows a simplified set of class declarations to correspond to part of the class hierarchy in Figure 9.2. All objects in the base class Person have data members ID, name, address, and phone that are common to all people. Those in the Student subclass inherit ID, name, address, and phone and have additional data members credits and GPA. The Faculty subclass also inherits the Person attributes but has its own data members dept and rank. In turn, Undergraduate and Graduate subclasses inherit the attributes of both Person and Student. We have indicated subclasses by using the keyword extends, although isa is sometimes used instead.

Each class declaration in Figure 9.3 includes methods for that class. Along with attributes, the methods of each superclass are also automatically inherited by the subclass so that, for example, Student and Faculty subclasses, as well as Student’s Undergraduate and Graduate subclasses, have the getName() and setName() methods from Person. The subclasses can also have additional methods, as we see for the subclass Student, which has methods getCredits() and addCredits(). The Undergraduate and Graduate subclasses inherit these methods as well, and each has its own methods: setMajor() and getMajor() for Undergraduate, and getProgram() for Graduate. We could override an inherited method by defining, for the subclass, a method that has the same signature as a method of the superclass, that is, the same name and the same number and types of parameters and return type. In that case, the new method will be used on objects of the subclass instead of the inherited method.

Multiple inheritance means that a subclass belongs to more than one superclass and that it inherits attributes and methods from the multiple superclasses. An example is shown in Figure 9.2, which shows a class for graduate teaching assistants as a subclass of both Graduate and Faculty. Each TeachingAssistant object has all the attributes and methods of Person, Faculty, Student, and Graduate, as well as attributes and methods of its own. We could add its class definition, shown in FIGURE 9.4, to the one in Figure 9.3.

Some OO languages do not support multiple inheritance and others restrict its use to only certain types of classes because it can cause problems if used carelessly. Our example can illustrate one of the problems. Because TeachingAssistant inherits from both Student and Faculty, each of which inherits the entire structure of Person, a TeachingAssistant object would have two copies of the Person structure, as well as the structures of Student, Faculty, and Graduate. If there are conflicts, there would be a problem deciding which structure should apply to a TeachingAssistant. For example, if Student has a method void promote(), which increases the student’s credits by 10, and Faculty has a method with the same signature that advances a faculty member’s rank to the next level, there is a conflict if we apply the promote method to a teaching assistant, because we cannot decide whether to increase the credits or advance the rank. Different OODBMSs handle this situation in various ways, so it is important to understand how the specific OO database system you are using resolves multiple inheritance conflicts.

9.2.4 Object Identity

Object identity is another fundamental concept for OO models. Each object in the database is assigned its own unique OID, which remains unchanged for the lifetime of the object. Unlike the relational model, where we must identify a primary key for each relation, the OO model provides unique identifiers automatically. The value of the OID does not depend on the value of any attribute of the object, such as ID in Person, nor is it the same as the name of the object. In the relational model, the primary key value could be updated. However, in the OO model, the OID never changes. Because it is always possible to tell objects apart by their OIDs, it is also possible that two different objects have the same values for all their data items, a situation forbidden in the relational model.