Inheritance and polymorphism (discussed below) are two sides of the same coin and represent very foundational concepts in object-oriented programming. The union design pattern is an expression of these relationships and enables us to talk about them in a more tangible manner.

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 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. Another way that we can express the notions depicted by the diagram is to say that the abstract ALiquid superclass represents the union of Coca Cola, sulfuric acid and milk. That is, a superclass represents the union of all of its subclasses.or in other words a superclass represents all that is abstractly equivalent about its subclasses.For instance, the notion of an abstract liquid embodies all the behaviors and attributes such as having no definite shape, randomized atomic positions, freezing and boiling points that are common to Coca Cola, sulphuric acid and milk. Note the fine distinction between having a value and having the same value.In general, an interface can be substituted for the abstract superclass discussed here with no loss of generality. The above diagram illustrating the relationship betwen 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.

Abstraction vs. Commonality A subtle but extremely important point is that 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. For instance, cats, dogs, humans, and rats are all mammals where a mammal is defined as an animal that produces milk to feed its young. One could thus make a class model where a superclass Mammal has subclasses Cat, Dog, Human and Rat. One common feature is behavior is that cats, dogs, humans and rats all give live birth of their young. So it is tempting to say that the Mammal class should also embody the "live birth" behavior. However, as one wanders the world discovering new mammals, in the backwaters of Australia one finds the duck-billed platypus which produces milk and is therefore clearly a mammal. However, the duck-billed platypus also lays eggs. Thus the "live birth" behavior does not belong in the Mammal superclass as it was only a coincidence that it was common to our initial set of subclasses. More importantly, being able to give live birth was never part of the abstract definition of a mammal and thus should never have been included in the Mammal superclass in the first place.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: boolean givesMilk() : returns true if the animal can give milk to feed its young, false otherwise String makeSound() : returns a String represenation of a common sound the animal makes. 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: Mammal Method boolean givesMilk() String makeSound() boolean givesLiveBirth() Cat true "Meow" true Monkey true "Screech" true Whale true "[whale song]" true

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

Model of Mammals No common methods defined in the superclass. Italics signify abstract methods or classesreturn_value : method_name(parameter_type_#1 parameter_name_#1, parameter_type_#2 parameter_name_#2, etc)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):

Model of Mammals Abstract and common methods hoisted to the superclass. 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: Mammal Method boolean givesMilk() String makeSound() boolean givesLiveBirth() Duckbilled Platypus true "growl" false

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):

Model of Mammals Properly abstracted model. 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.Abstraction levels are links in a chain. A chain is only as strong as its weakest link. A program is only as abstract as its lowest abstraction level. Levels of abstraction illustrate another important aspect of an OO program. Since a superclass represents the union of the subclasses or conversely, that the superclass can be represented by any of its subclasses, we see that the superclass is an embodiment of all the invariant aspects of the subclasses. That is, the superclass's definition is all that is abstractly equivalent about the subclasses--all that does not change from subclass to subclass. Note that this does not imply that the values of common fields are necesarily the same, just that, perhaps, that the field exists. Not does it imply that what is common to all the subclasses is necessarily what is abstractly equivalent about them (see the note above). The differences between the subclasses is what creates the variations in how the program behaves when any given subclass is used in place of the superclass. We call this the variant aspects of the system. The total behavior of a program is the combination of its variant and invariant behaviors.

Inheritance and Polymorphism Inheritance and polymorphism are really just two ways of looking at the same class relationship. Inheritance is looking at the class hierarchy from the bottom up. A subclass inherits behaviors and attributes from its superclass. A subclass automatically possesses certain behaviors and/or attributes simply because it is classified as being a subclass of an entity that possesses those behaviors and/or attributes. That is, a cherry can be said to automatically contain a seed because it is a subclass of Fruit and all fruit contain seeds. Inheritance is useful from a code reuse perspective. Any (non-private) code in the superclass does not have to be replicated in any of the subclasses because they will automatically inherit those behaviors and attributes. However, one must be very careful when transferring common code from the subclasses to the superclass (a process called "hoisting"), as the proper abstraction represented by the superclass may be broken (see note above). Polymorphism, on the other hand, is looking at the class hierarchy from the top down. Any subclass can be used anywhere the superclass is needed because the subclasses are all abstractly equivalent to the superclass. Different behaviors may arise because the subclasses may all have different implementations of the abstract behaviors defined in the superclass. For instance, all liquids have a boiling temperature. They may have different values for that boiling temperature which leads to different behaviors at any given temperature. Polymorphism is arguably the more useful perspective in an object-oriented programming paradigm. Polymorphism describes how an entity of a lower abstraction level can be substituted for an entity of a higher abstraction level and in the process, change the overall behavior of the original system. This will be the cornerstone that enables us to build OO systems that are flexible, extensible, robust and correct.

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

Is the following legal code? IBinaryOp bop = new IBinaryOp(); No, it won't compile. IBinaryOp is an interface and does not specify any actual executable code, so it cannot be instantiated. Is the following legal code? IBinaryOp bop = new AddOp(); Yes! AddOp is an concrete class and can be instantiated. AddOp is an IBinaryOp (technically, AddOp implements the IBinaryOpinterface), so bop can reference it. Given the above declaration and assignment of bop, is the following assignment then possible? bop = new MultOp(); Yes, for the same reasons as the previous exercise! MultOp is an concrete class and can be instantiated. MultOp is an IBinaryOp, so bop can reference it. Suppose we have bop = new AddOp(); , what is the result of bop.apply(5,3) ? The result is 8 because bop refers to an AddOp instance, whose apply method adds its two input values. Suppose we now say bop = new MultOp(), what is the result of bop.apply(5,3) now? The result is 15 because bop now refers to an MultOp instance, whose apply method multiplies its two input values. Suppose we have some variable, called myOp of type IBinaryOp what is the result of myOp.apply(5,3)? It is impossible to tell because it depends on the exact type of the object instance to which myOp refers. Suppose we have bop = new MultOp(), is it legal to call bop.getDescription() ? No, because bop is a variable of type IBinaryOp , which is not defined as having a getDescription method. This is true even if bop references an object of type MultOp. This is because the static typing of bop tells the compiler that it references an IBinaryOp, not the particular concrete type of the object it currently references. If we had MultOp mop = new MultOp(), then mop.getDescription() is perfectly legal. Is the following legal code? AddOp aop = new AddOp() Yes, because aop is a variable of type AddOp, and thus can reference an instance of the same type. Given the declaration in the previous exercise, is the following legal? aop = new MultOp() No, because aop is a variable of type AddOp , and MultIOp is not an AddOp, so aop cannot reference an instance of MultOp. 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; Yes! bop is a variable of type IBinaryOp, and aop is defined as referencing an AddOp object, which is an IBinaryOp . Is the converse legal as well? That is, using the above definitions, can we compile and run the following statement? aop = bop; Not as written, because bop is a variable of type IBinaryOp (i.e. staticly typed as such), which and does not necessarily reference an object of type AddOp. to which aop must reference. That is, a variable of the type of the superclas can always reference an object of the type of any subclass, but a variable of the type of a particular subclass cannot necessarily reference something of the type of its superclass. Another way of saying this is that a superset contains its subsets but not the other way around. The above assignment will cause a compile time error because the compiler cannot know if the assignment is possible. An explicit cast is required to supress the compile time error (aop = (AddOp) bop), but may trigger a run-time error if indeed the instance referred to by bop is not of type AddOp.