Comp201: Principles of Object-Oriented Programming I
Spring 2006 -- Union Design Pattern: Inheritance and Polymorphism   

Union Design Pattern

Consider the following "is-a" or inheritance relationships between "concrete" entities Coca Cola, sulfuric acid, milk and the "abstract" liquid (named "ALiquid" by convention since it is an abstract entity):

 

Union of Liquids Figure 1: ALiquid is the union of CocaCola, SulfuricAcid and Milk

 

The UML diagram shows us that Coca Cola, sulfuric acid and milk are all liquids. Conversely, the diagram tells us that a liquid could be either Coca Cola, sulfuric acid or milk. Note of course, that liquids are not constrained to these 3 entities but that doesn't affect the discussion here--in fact, this will be an important feature later on.

a superclass represents the union of all of its subclasses.

a superclass represents all that is abstractly equivalent about its subclasses.

Using interfaces: In general, an interface can be substituted for the abstract superclass discussed here with no loss of generality.

The above diagram illustrating the relationship between a superclass and its subclasses is called the Union Design Pattern.  The union pattern shows us inheritance in how the Coca Cola, sulfuric acid and milk will all inherit the abstract behaviors of liquids, such as the lack of a definite shape and freezing/boiling points.  Conversely, it also shows that if a situation utilizes a liquid, either Coca Cola, milk or sulphuric acid can be used as they are all abstractly equivalent as liquids. Note that this does not imply that all three will act identically!  For instance, the human throat can swallow any liquid because it is made to work with fluids that can flow.  However, the reaction of the throat to sulphuric acid is markedly different than it reaction to milk!  This ability to substitute any subclass for its superclass and get different behavior is called polymorphism.

A subtle but important point: Commonality does not imply abstract equivalence.  Just because a feature is common to every item in a set, does not necessarily mean that it represents some sort of abstract feature of those elements.

Cats, monkeys and whales, while diverse creatures, are all mammals. Hence to model such a system in the computer, it makes sense to make Cat, Monkey and Whale all subclasses of an abstract Mammal superclass. Each species has many behaviors (methods) but I will only concentrate on 3 in particular:

1. boolean givesMilk() : returns true if the animal can give milk to feed its young, false otherwise
2. String makeSound() : returns a String represenation of a common sound the animal makes.
3. boolean givesLiveBirth(): returns true if the animal bears live young.

In the table below are the methods and what happens when each species executes that method:

We could start out with the following class implemenation (Mammal0.java):

Let's start our analysis:

• A mammal is defined by the fact that it gives milk to feed its young. It is thus not surprising that all the givesMilk() methods in the subclasses return true. The givesMilk() method is a prime candidate for "hoisting" up into the Mammal superclass ("hoisting" =  moving the method upwards from the subclass to the superclass).
• makeSound() returns a different value for each species, but intrisically, we expect any animal, which includes mammals, to be able to make some sort of sound. Thus Mammals should have a makeSound() method, but since, at the Mammals level, we don't know exactly how that sound will be made, the method at that level must be abstract. The makeSound()method at the concrete Cat, Monkey and Whale level however, would be concrete because each animal makes its own unique sound.
• givesLiveBirth() returns exactly the same value for all of our rather diverse selection of animals here. It seems like a fine candidate for hoisting. Or is it....? Let's go ahead an hoist it anyway.

This is what we have so far (Mammal1.java):

Before we go charging ahead, let's stop for a moment and review what we've done: Cats, monkeys, and whales do represent a wide spectrum of mammals, but remember, the abstract Mammal class is a representation of ALL mammals, not just the ones we have so far. The correlation of like behavior with all our represented animals does not imply its inclusion in their abstract representation!

For instance, one day, in our wanderings through Australia, we encounter a Duckbilled Platypus. Let's see how it behaves with respect to our 3 methods:

Duckbilled platypus lay eggs!!

Giving live birth is not part of the definition of a mammal. On the other hand, the question of whether or not the animal gives live birth can always be asked of any animal, including all mammals. The result may be true or false however, so the method must be abstract at the Mammal level.

Our class structure should look like this (Mammal2.java):

Hoisting does not guarantee proper abstraction. Hoisting should be driven by a need for abstraction, not by coincidence.

Another key notion that the union pattern emphasizes is levels of abstraction. What we see is that the concept of a liquid is more abstract than milk. In turn, the general concept of milk is more abstract than "2% milk" or "skim milk" which would be subclasses of milk. In general we can see that a superclass is a distinctly higher level of abstraction than any of its subclasses. One of the key tools we use to help us design and build high quality object-oriented systems is careful attention to the abstraction level at any given moment.

Good OOP code always maintains a consistent level of abstraction.

The total behavior of a program is the combination of its variant and invariant behaviors.

Exploring Polymorphism

Let's explore some different ways in which polymorphism presents itself. Consider the following example of the union design pattern:

	/**
	* An interface that represents an operation on two doubles
	*/
	public interface IBinaryOp {
	    double apply( double x, double y);  // all interface methods are public and abstract by default
	}
	
	/**
	* An IBinaryOp that adds two numbers
	*/
	public class AddOp implements IBinaryOp {
	    public double apply( double x, double y) {
	        return x+y;
	    }
	}	
	
	/**
	* An IBinaryOp that multiplies two numbers
	*/
	public class MultOp implements IBinaryOp {
	    public double apply( double x, double y) {
		return x*y;
	    }
		
	    public String getDescription() {
		return "MultOp is a multiplying function.";
	    } 
	}	
	

Problem 1:

Is the following legal code? IBinaryOp bop = new IBinaryOp(); 

 

Problem 2:

Is the following legal code? IBinaryOp bop = new AddOp();

 

Problem 3:

Given the above declaration and assignment of bop, is the following assignment then possible? bop = new MultOp();  

 

Problem 4:

Suppose we have bop = new AddOp(); , what is the result of bop.apply(5,3)?  

 

Problem 5:

.

Suppose we now say bop = new MultOp(), what is the result of bop.apply(5,3) now? 

 

Problem 6:

Suppose we have some variable, called myOp of type IBinaryOp what is the result of myOp.apply(5,3)? 

 

Problem 7:

Suppose we have bop = new MultOp(), is it legal to call bop.getDescription()? 

 

Problem 8:

Is the following legal code? AddOp aop = new AddOp();  

 

Problem 9:

Given the declaration in the previous exercise, is the following legal? aop = new MultOp(); 

 

Problem 10:

Suppose we have definitions of aop and bop from above. Is the following legal? That is, can we compile and run the folowing statement without error? bop = aop; 

 

Problem 11:

Is the converse legal as well? That is, using the above definitions, can we compile and run the following statement? aop = bop;  

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

©2006 Stephen Wong and Dung Nguyen