"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.

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

UML Class Diagram Showing Inheritance

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.

public class Apple extends Fruit {
	...
}

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

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
	}
}

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

UML Class Diagram Showing Implementation

"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.

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

UML Class Diagram Showing Composition

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.