Comp201: Principles of Object-Oriented Programming I
Spring 2006 -- Lec05: Object Relationships and UML Diagrams   

Summary: Relationships between objects can be classified as either "is-a" (inheritance) or "has-a" (composition). These two relationships enable the OO software designer to create abstract models of the desired system.

 

An object-oriented system can be characterized as a system of cooperating objects. Some objects interact only with certain other objects or perhaps only with a certain set of objects. Sometimes objects are treated as equivalent even though there may be specific differences between them, for instance a situation may call for a "fruit" whereupon an "apple" will do just as well as an "orange". That is, apples and oranges are treated as abstractly equivalent. Conversely, the system designer may want to express the commonality between apples and oranges. An OO system has two distinct mechanisms to express these relationship notions: "is-a" which is technically referred to as "inheritance" and "has-a" which is technically referred to as "composition".

"Is-a" or "Inheritance"

"Is-a" or "inheritance" (sometimes also called "generalization") relationships capture a hierarchal relationship between classes of objects. For instance, a "fruit" is a generalization of "apple", "orange", "mango" and many others. We say that fruit is an abstraction of apple, orange, etc. Conversely, we can say that since apples are fruit (i.e. an apple "is-a" fruit), that they inherit all the properties common to all fruit, such as being a fleshy container for the seed of a plant.

 

UML Class Diagram Showing Inheritance
 

Figure 1: The above diagram shows the "is-a" relationship between Apple, Orange and Mango subclasses and the more abstract Fruit superclass.
 
UML Syntax note:    classes and inheritance lines

classes -- represented by boxes with the class name separated at the top by a horizontal line.

inheritance ("is-a") lines -- represented by solid lines with solid arrowheads.  The arrow points from the subclass to the superclass (think "a subclass object is-a superclass object")

 

In Java, inheritance relationships are declared using the extends keyword when declaring a class. A subclass "extends" a superclass, which means that the subclass is a concrete example of the more abstract superclass. For instance, the class Apple would extend the class Fruit. 
class Apple extends Fruit {
	...
}
In Java, a subclass is allowed to extend only a single superclass (no "multiple inheritance"). This restricts the interpretation of a hierarchal taxomony. A subclass is an embodiment of its superclass. It is useful to think of the subclass as not inheriting its superclass's behaviors but rather possessing these behaviors simply because it is the superclass (this is polymorphism). extends really models what an object intrinsically is--its true "being" as it were. This is particularly useful when the superclass has particular concrete behaviors that all the subclasses should exhibit.
 
However, "is-a" can really be more of an "acts-like-a" relationship. This stems from the perspective that all objects are defined soley by their behaviors. We can never truly know what an object truly is, only how it acts. If two objects behave identically (at some abstract level) then we say that they are abstractly equivalent. What we need is a way to express the pure behavioral aspects of an object. Java has a the keyword implements which is used to show generalization of a pure behavioral abstraction called an interface. An interface has a similar syntax to a class, but only specifies behaviors in terms of the "signatures" (the input and output types) of the methods. For example we could have

Note:  You must use at least "Advanced Language Level" in DrJava for the following code!

public interface ISteerable {
	public abstract void turnLeft();
	public abstract void turnRight();
}

public class Truck implements ISteerable {
	public void turnLeft() {
		// turn the tires to the left
	}
	public void turnRight() {
		// turn the tires to the right
	}
}

public class Boat implements ISteerable {
	public void turnLeft() {
		// turn the rudder to the left
	}
	public void turnRight() {
		// turn the rudder to the right
	}
}
 
Syntax note:    keywords public, abstract and void

public-- can be seen and used by anyone.   Contrasts with private (seen and used only by that class) and package (seen and used only by classes in the same package).  We'll talk more about these later.

abstract -- a purely abstract definition in that it specifies the existence of a behavior without specifying exactly what that behavior is.  

void -- a non-existent return value, that is, no return value at all.

Above, Trucks and Boats are not taxonomically related, but yet they both embody the behaviors of steerability, such as the ability to turn left or right. A person can pilot either a boat or a truck based soley on the fact that they both support turning left or right and not based on what sort of entity they are fundamentally. Note that as per the above definition, a class can implement multiple interfaces at the same time.

 
UML Class Diagram Showing Implementation
 

Figure 2: The above diagram shows the "acts-like-a" relationships between ISteerable, Boat, and Truck classes
 

UML Syntax note:    implementation lines

implementation ("acts-like-a") lines -- represented by dotted lines with solid arrowheads.  The arrow points from the subclass to the interface (think "a subclass object acts-like-a interface")

 

 

"Has-a" or "Composition"

"Has-a" or "composition" (sometimes referred to as an "associative") relationships capture the notion that one object has a distinct and persistant communication relationship with another object. for instance, we can say a car "has-a" motor. The car and the motor are not related in a hierarchal manner, but instead we need to be able to express that this pair of objects has a particular working relationship. The car gives gas to the motor and the the motor will propel the car along. Compositional relationships can be one-way, where one object can, in a persistant manner, talk to (i.e. call methods of) a second object but the second object cannot, in a persistent manner, talk back to the first object. Compositional relationships can also be two-way, where both objects can talk to each other in a persistent manner.

 

UML Class Diagram Showing Composition
 

Figure 3: The above diagram shows the "has-a" relationships between the Car, Motor and Wheel classes

 

The emphasis made above with regards to persistent communication is deliberate and important. It is indeed possible for an object to communicate with another object in a non-persistent manner. Such non-persistent communication is generally not thought of as a compositional relationship, but rather as a dependency relationship where the action of one object depends on that of another. An object can tell a second object that it (the second object) needs to talk to a specific, perhaps third object. The second object does not know with whom it will be communicating until the first object tells it. The second object may not "remember" the object it is supposed to communicate with for any length of time after the communication was accomplished and the second object merely waits for the first object to tell it with whom to communicate next. This non-persistent communication is normally established by simply passing the third target object as an input parameter to the method call made on the second object by the first. Note that the third object could actually be the first object, creating a non-persistent two-way communication from an initially one-way communication.

 

Last Revised Thursday, 03-Jun-2010 09:50:14 CDT

©2006 Stephen Wong and Dung Nguyen