You are here

"Is-a" or "Inheritance"

26 July, 2019 - 09:51
Available under Creative Commons-ShareAlike 4.0 International License. Download for free at

"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.1 UML Class Diagram Showing Inheritance 
The above diagram shows the "is-a" relationship between Apple, Orange and Mango subclasses and the more abstract Fruit superclass. 
Note: Classes are represented by boxes with the class name separated at the top by a horizontal line.
Note: Inheritance ("is-a") lines are 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.

public 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). Extend 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 solely 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 } } 
Note: A public class, method or field 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. An abstract class or method is a purely abstract definition in that it specifies the existence of a behavior without specifying exactly what that behavior is. A void return type declares 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 steer-ability, such as the ability to turn left or right. A person can pilot either a boat or a truck based solely 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.

Figure 1.2 UML Class Diagram Showing Implementation 
The above diagram shows the "acts-like-a" relationships between ISteerable, Boat, and Truck classes 
Note: Implementation ("acts-like-a") lines are represented by dotted lines with solid arrowheads. The arrow points from the subclass to the interface (think "a subclass object acts like-a interface")