© 2006-2007 Carl Alphonce & Adrienne Decker 1 ; Chapter 7 Inheritance: Modeling subtype relationships ; Pedagogic Goals Show how a system can be made flexible and resilient through the use of abstract specifications over concrete implementations. Demonstrate how different subtyping relationships identified in a model can be implemented using different forms of inheritance. Introduction A key part of building a model of a system is to identify the types from the system’s domain which are relevant to the operation of the system, as well as the ways in which parts of the system communicate with each other. We now know the two ways to introduce new types into Java’s type system: defining an interface and defining a class. We have also learned that implementation of an interface by a class is called the realization relationship. When a class realizes an interface the class’ type becomes a subtype of the interface’s type. The importance of this is that we can use an instance of a subtype whenever the supertype is called for. The ability to use a subtype object to satisfy a supertype constraint allows us to write generic code – code that will work with many different (sub)types of objects. It all comes down to decoupling of components. If we couple components closely by making a client component dependent on a specific class we end up with a very rigid and brittle system. On the other hand, if we decouple components by making a client dependent only on an interface, then that client can work with any implementor of the interface. We end up with a flexible and resilient system. In the last chapter we explored how the multiple roles that an object may play in a system can be modeled by having the roles cast as interfaces and by having the object’s class defined to implement each of those interfaces. We saw how polymorphism came about by having a capability specified in a supertype and having different subtypes implement that capability in different ways. In this chapter we will learn that not only interfaces can play the role of supertype, but also classes. Defining a class as a subclass of another class involves yet another relationship. This relationship goes by many different names, including inheritance, generalization, and extension.1 Like realization, generalization is a form of subtyping relationship. Unlike 1 It is not uncommon to see the relationship referred to as an “is a” relationship, because a subtype object is also of the supertype. The Liskov substitution principle requires that subtype objects must be substitutible for supertype objects; some cases of “is a type of” do not fit this mold because the “subtype” is a restriction of the supertype, not an extension of it. “Uncle Bob” Martin discussed a marvelous example of this at the 2006 OOPSLA Educators’ Symposium, showing that while we think of squares as a special type of rectangle, it is entirely inappropriate to model the relationship between these types using inheritance because while a square is aError! Use the Home tab to apply Chapter Title to the text that you want to appear here. Inheritance: Modeling subtype relationships 2 9/29/2008 realization, which is a relationship holding only between a class (as the subtype) and an interface (as the supertype), generalization can occur between two classes or between two interfaces. This chapter explores what this relationship, in its many forms, models. The generalization relationship in UML The generalization relationship, because it can occur between two interfaces or between two classes, will show up in UML class diagrams in one of two ways, as demonstrated in the diagrams below. What is common to both diagrams is that the relationship is represented by a solid line with a triangle at the target end of the relationship. Generalization between interfaces is shown in the left diagram, and generalization between classes in the right diagram. The generalization relationship in code The generalization relationship is expressed using the extends keyword in the interface or class header, as shown in the code snippets below, corresponding to the diagram above. First we see the code for interface extension: package chapter6.generalizationInUML; /** * @author <a href="mailto:[email protected]">Carl G. Alphonce</a> * * Created on: Oct 24, 2006 * */ public interface ISource extends ITarget { } This expresses that the type introduced by the interface ISource is a subtype of the type introduced by the interface ITarget. The details of what this means is discussed in the next section. Next, we see the code for class extension. The class header uses the extends keyword to identify the target class of the extension: rectangle, it is a restriction, not an extension, of a rectangle. Because of this, we avoid using the name “is a” for this relationship.Interface extension © 2006-2007 Carl Alphonce & Adrienne Decker 3 package chapter6.generalizationInUML; /** * @author <a href="mailto:[email protected]">Carl G. Alphonce</a> * * Created on: Oct 24, 2006 * */ public class Source extends Target { /** * Creates a new instance of Source */ public Source() { } } This expresses that the type introduced by the class Source is a subtype of the type introduced by the class Target. The details of what class extension implies is discussed later in the chapter. Interface extension To understand why subtyping is important, let us explore some examples. First, suppose we have a system in which multiple roles occur, and we wish to model that some roles sometimes must co-occur (occur simultaneously).Error! Use the Home tab to apply Chapter Title to the text that you want to appear here. Inheritance: Modeling subtype relationships 4 9/29/2008 Example 1 Students at university follow a particular course of study, called their major. Different programs of study are often grouped together according to the “general education” requirements they impose. Arts, Science and Engineering programs often have different general education requirements. For example, a student might major in Linguistics (an Arts program), Computer Science (a Science program), or Biomedical Engineering (an Engineering program). Most students have just one major. Some students decide to pursue two majors at the same time. This requires that students satisfy the general education requirements of both majors. The