cop 3330: object-oriented programming summer 2007 inheritance and polymorphism – part 1

49
COP 3330: Inheritance Page 1 © Mark Llewellyn COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1 School of Electrical Engineering and Computer Science University of Central Florida Instructor : Mark Llewellyn [email protected] HEC 236, 823-2790 http://www.cs.ucf.edu/courses/cop3330/ sum2007

Upload: eden-dodson

Post on 30-Dec-2015

37 views

Category:

Documents


1 download

DESCRIPTION

COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1. Instructor : Mark Llewellyn [email protected] HEC 236, 823-2790 http://www.cs.ucf.edu/courses/cop3330/sum2007. School of Electrical Engineering and Computer Science - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 1 © Mark Llewellyn

COP 3330: Object-Oriented ProgrammingSummer 2007

Inheritance and Polymorphism – Part 1

School of Electrical Engineering and Computer ScienceUniversity of Central Florida

Instructor : Mark Llewellyn [email protected]

HEC 236, 823-2790http://www.cs.ucf.edu/courses/cop3330/sum2007

Page 2: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 2 © Mark Llewellyn

Object-Oriented Design

• The concept of inheritance is important in the design of software systems.

– It provides a way of organizing the components of the system in a hierarchical manner. The hierarchy helps one to understand the system.

– In addition, it provides a framework for reusing code.

• Inheritance is used typically to organize abstractions in a top-down fashion from the most general (least specific) to the least general (most specific). Consider the hierarchy shown in the next slide.

Page 3: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 3 © Mark Llewellyn

Object-Oriented Design (cont.)

Cars

BMW Ferrari PorscheMercedes

C-class E-class

E-350 E-500

S-class

E-500-AMG

A partial outline of a car hierarchy

Page 4: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 4 © Mark Llewellyn

Object-Oriented Design (cont.)

• The partial car hierarchy shown in the previous slide illustrates the hierarchical concept of moving from the general to the specific as you move down the hierarchy.

– The hierarchy is organized according to different manufacturers of cars and their various models.

– Understanding the hierarchy enables one to recognize and distinguish shared and distinguishing characteristics of different types of cars.

– At the top of the hierarchy is the most general representation, which in this specific hierarchy is simply a car.

– According to the hierarchy, cars fall into one of four categories: BMW, Mercedes, Ferrari, and Porsche.

Page 5: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 5 © Mark Llewellyn

Object-Oriented Design (cont.)

– Within the specific category of Mercedes cars (moving down the hierarchy), we see that Mercedes cars are further classified into one of three subcategories: C-class, E-class, and S-class.

– Moving even further down the hierarchy, we see that the subcategory of E-class Mercedes are again further classified into one of three sub-subcategories: E-350, E-500, and E-500-AMG categorized depending upon the various features of each model.

– Therefore, we can look at E-350s differently than E-500s, yet they share all of the characteristics of an E-class model and similarly they share all of the characteristics of a Mercedes, and so on, up the hierarchy.

Page 6: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 6 © Mark Llewellyn

Object-Oriented Design (cont.)

• In object-oriented programming languages, a class created by extending another class is known as a subclass.

• The class used as a basis for a subclass is its superclass.

– Sometimes a superclass is also referred to as a base class and the subclass is then referred to as the derived class.

• In general, a subclass can provide both additional data fields and methods. This is illustrated in the next slide using the car hierarchy from page 3.

Page 7: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 7 © Mark Llewellyn

Some Relationships in the Car Hierarchy

CarsMercedesE-classE-350

E-350s are type of E-class; i.e., they are a subcategory of E-class models. In programming terminology they are a subclass of the class E-class models.

E-class models are a type of Mercedes; i.e., they form a subclass of Mercedes cars.

Mercedes’ are a type of car; i.e., they form a subclass of cars. According to the hierarchy on page 3, there are three other subclasses of cars that have been identified.

Page 8: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 8 © Mark Llewellyn

Object-Oriented Design (cont.)

• One complication with regard to inheritance for beginning OO programmers is the fact that a subclass object has multiple types.

• The subclass object is a specialized superclass type object. Therefore, the subclass object is of both the subclass and superclass types.

• With inheritance, there is an is-a relationship between the subclass type and its superclass type. For example, an E-320 is an E-class and it is also a Mercedes.

Page 9: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 9 © Mark Llewellyn

Object-Oriented Design (cont.)

• Now let’s change our focus from the simple concept of inheritance to using inheritance as a programming mechanism.

• We’ll start off by using inheritance to extend a built-in Java class and then move on into extending classes that we’ll construct ourselves.

• For starters, we’ll extend the awt class to support several different application needs. In particular, we’ll extend Java’s Point class that we have used in previous examples in the course.

Page 10: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 10 © Mark Llewellyn

Extending The Point Class

• The awt class Point provides a representation of a 2-dimensional point. We’ve used this class before (see ??? for example).

• Using inheritance we will build upon this 2-dimensional point representation to create a 3-dimensional point class representation, ThreeDPoint. The new class ThreeDPoint extends class Point by adding a new property that the Point class does not have, namely, a z-coordinate value.

Page 11: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 11 © Mark Llewellyn

Extending The Point Class (cont.)

• This new property can be maintained by using a public data field z. To support encapsulation and information hiding, ThreeDPoint provides an accessor method getZ() and a mutator method setZ() for the new z-coordinate property.

z-axis

x-axis

y-axis

Point (x,y,z) in 3-

dimensional space

Page 12: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 12 © Mark Llewellyn

Extending The Point Class (cont.)

• Since we are extending the class ThreeDPoint from Point. ThreeDPoint inherits the Point x-coordinate and y-coordinate attributes and Point accessor and mutator methods getX(), getY(), setX(), and setY().

– We’ll use these accessors and mutators in our implementation of ThreeDPoint. The use of these methods is not strictly necessary because the Point class makes its attributes public (which is also why we made coordinate z a public data field). Our implementation uses these methods because the use of mutators and accessors is a good practice – superclass attributes are almost always private (the Point class is a rare exception to this rule). In the typical case, a subclass cannot directly access the attributes, and instead must use the available superclass accessors and mutators to manipulate the superclass attributes.

Page 13: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 13 © Mark Llewellyn

Extending The Point Class (cont.)

• Unless we indicate otherwise, the ThreeDPoint class also inherits the Point class facilitators, e.g., translate(), toString(), equals(), and clone(). However, these Point facilitators are not suitable in a 3-dimensional context – they aren’t aware of the z-coordinate values. Therefore, the ThreeDPoint class must provide its own versions of these methods .

• We’ll look at each of these methods separately.

Page 14: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 14 © Mark Llewellyn

It’s All Inherited in Java

• Remember that all classes are either explicitly or implicitly an extension of the class Object. The relationship between ThreeDPoint, Point, and Object are illustrated in the following diagram.

ThreeDPoint Point Object

Class representing locations with x-, y-, and z- coordinates.ThreeDPoint is a subclass ofPoint.

Class representing locations with x- and y- coordinates.Point is a subclass of Object.

Superclass of all Javaobjects.

Class Object provides basic versions of several methods including: toString(), equals(), and clone(). It also has methods finalize(), getClass(), hashCode(), notify(), notifyAll(), and wait(). These are all inherited by the subclasses of Object.

Page 15: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 15 © Mark Llewellyn

ThreeDPoint Class Method translate()

• The ThreeDPoint method translate() will have three parameters representing the increment in the x, y, and z coordinates.

• Since the method signatures of the ThreeDPoint and Point versions of translate() are different, the method name translate() is overloaded in the ThreeDPoint class.

– This means that with a ThreeDPoint object both methods are available. Java determines which method is in use by the number of parameters in a given invocation.

ThreeDPoint a = new ThreeDPoint(5, 20, 47);a.translate(1,1); //invocation of superclass translatea.translate(2,2,2); //invocation of subclass translate

Page 16: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 16 © Mark Llewellyn

ThreeDPoint Class Methods toString(), equals(), and clone()

• The ThreeDPoint methods toString(), equals(), and clone() should not have different signatures from the Point versions.

– By having the same signatures as their superclass counterparts, the subclass methods override the superclass definitions for ThreeDPoint objects. The overriding enables the subclass-specific nature of the ThreeDPoint objects to be considered.

ThreeDPoint c = new ThreeDPoint(1, 3, 5);ThreeDPoint d = (ThreeDPoint) c.clone();//cast is necessary//as apparent type of return value of subclass method clone() is Object String s = c.toString(); //invocation of subclass toString() methodboolean b = c.equals(d); //invocation of subclass equals() method

Page 17: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 17 © Mark Llewellyn

The ThreeDPoint Class//representation of a 3-d pointpackage geometry;import java.awt.*;

public class ThreeDPoint extends Point{ //private class constant private final static int DEFAULT_Z = 0;

//instance variable public int z = DEFAULT_Z;

//ThreeDPoint(): default constructor public ThreeDPoint(){ super(); }

//ThreeDPoint(): specific constructor public ThreeDPoint(int a, int b, int c){ super(a,b); setZ(c); }

Page 18: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 18 © Mark Llewellyn

//getZ(): z-coordinate accessor public double getZ(){ return z;

} //setZ(): z-coordinate mutator public void setZ(int value){ z = value; }

//translate(): shifting facilitator public void translate(int deltax, int deltay, int deltaz){ translate(deltax, deltay); int zValue = (int)getZ(); setZ(zValue+deltaz); }

//toString(): conversion facilitator public String toString(){ int a = (int)getX(); int b = (int)getY(); int c = (int)getZ();

return getClass() + “[“ + a + “,” + b + “,” + “,” + c + “]”;}

Page 19: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 19 © Mark Llewellyn

//equals(): equality facilitator public boolean equals(Object v){ if (v instanceof ThreeDPoint){ ThreeDPoint p = (ThreeDPoint) v; int z1 = (int) getZ(); int z2 = (int) p.getZ(); return super.equals(p) && (z1 == z2); } else { return false; } }

//clone(): cloning facilitator public Object clone(){ int a = (int) getX(); int b = (int) getY(); int c = (int) getZ(); return new ThreeDPoint(a,b,c); }}//end class ThreeDPoint

Page 20: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 20 © Mark Llewellyn

Explanations for the ThreeDPoint Class

• ThreeDPoint begins with a package statement. A package statement indicates that the definitions that follow are part of a bigger collection known as a package. In this case, the bigger package is called geometry.

package geometry;

Keyword package indicates that the definitions that follow are part of a package. An element of a package has special access rights with regards to the other elements of the package.

package name

Page 21: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 21 © Mark Llewellyn

Packages

• We have used packages (e.g., swing, awt, math, and io) in many of the sample programs we written. However, class ThreeDPoint is the first class that we have defined to be part of a package.

• Programmers put classes and interfaces into a package for two basic reasons:

1. Organization: By organizing classes and interfaces with a related purpose into a package, you make it easier for users to find them – classes and interfaces with the same package name are stored in the same folder. In addition, Java puts the classes of one package in a different namespace (scope) than it puts the classes of another package. As a result, the names in a package do not conflict with names in other packages.

Page 22: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 22 © Mark Llewellyn

Packages (cont.)

2. Special access to members: When defining members of a class or interface, Java does not require an explicit access specification. The implicit specification is known as default access. Members of a class with default access can be accessed only by members of the package.

• If a Java files does not begin with a package statement, then all the definitions in that file are considered to be part of a package unique to that file.

Page 23: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 23 © Mark Llewellyn

Keyword Extends

• Keyword extends is Java’s mechanism for deriving a new class from an existing class. Programmers often read this statement as

“ThreeDPoint is a kind of Point.”

• Except for the use of the extends, defining a subclass is not very different from defining a superclass.

• When differences do arise they are most commonly found in the constructor definitions.

public class ThreeDPoint extends Point {

Keyword extends indicates that class ThreeDPoint is a subclass of

its superclass Point

Page 24: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 24 © Mark Llewellyn

Class Constants and Instance Variables in a Subclass

• The ThreeDPoint class first defines a private class constant DEFAULT_Z and a public instance variable z.

• Adding a member to a subclass does not require special syntax. Therefore, the DEFAULT_Z and z definitions have the expected form:

//private class constant private final static int DEFAULT_Z = 0;

//instance variable public int z = DEFAULT_Z;

Page 25: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 25 © Mark Llewellyn

Constructors in a Subclass

• The definitions of the ThreeDPoint class constructors differ from the definitions of previous constructors in their use of the keyword super.

//ThreeDPoint(): default constructor public ThreeDPoint(){ super(); }

//ThreeDPoint(): specific constructor public ThreeDPoint(int a, int b, int c){ super(a,b); setZ(c); }

Invocation of default superclass constructor

Invocation of specific superclass constructor

Page 26: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 26 © Mark Llewellyn

Constructors in a Subclass (cont.)

• Because a ThreeDPoint object is an extended version of a Point object, the construction of a ThreeDPoint object begins with the construction of its superclass attributes (i.e., x- and y- coordinate values).

• To initialize these attributes, a superclass constructor must be invoked. The superclass invocation can be explicit or implicit.

• Since a subclass is a specialization of the superclass, a constructor for the superclass must be invoked to create a superclass object before the constructor for the subclass can do its specialization. (Parallel – if you are going to build a Mercedes E-350 you don’t start out on a Ford assembly line!)

Page 27: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 27 © Mark Llewellyn

Constructors in a Subclass (cont.)

• The superclass object must exist before it can be turned into a specialized subclass object.

• To invoke explicitly a superclass constructor for the object under construction, use the keyword super.

• Keyword super is the Java mechanism for viewing the current object as an instance of the superclass.

Page 28: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 28 © Mark Llewellyn

Constructors in a Subclass (cont.)

• This statement from the ThreeDPoint default constructor definition is an explicit invocation of the superclass’s default constructor on the object under construction.

• Since the superclass of ThreeDPoint is Point, it is the Point default constructor that is invoked for the object under construction.

• The Point default constructor takes care of the initialization of the x- and y- coordinate values. This action is the only explicit work required for the initialization process, because z- coordinate instance variable definition specifies the initial value for instance variable z.

super();

Page 29: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 29 © Mark Llewellyn

Constructors in a Subclass (cont.)

• The other ThreeDPoint constructor initializes the object under construction to the given x-, y-, and z- coordinate values. This constructor also explicitly invokes a superclass constructor.

• The invocation uses the Point constructor to properly set the x- and y- coordinate values. To complete the initialization, the z- coordinate is set to the desired values using mutator setZ();

super(a,b);

setZ(c);

Page 30: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 30 © Mark Llewellyn

Constructors in a Subclass (cont.)

• If a subclass constructor does not invokes explicitly a superclass constructor, then Java automatically invokes the superclass’s default constructor to initialize the superclass attributes.

– This means that we could have written our ThreeDPoint default constructor definition without explicitly invoking super().

– Since it is simpler to omit the explicit invocation than to type it in, most constructor code makes use of the implicit invocation of super().

public ThreeDPoint() { //implicit super() invocation before //mutator invocation}

Page 31: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 31 © Mark Llewellyn

Constructors in a Subclass (cont.)

• Notice that the constructors in the ThreeDPoint class are both quite short. This is possible since we are able to reuse the code that was developed for the superclass.

• With this small example, the savings in code may not be that great, but with more complex classes, the savings can be substantial.

Page 32: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 32 © Mark Llewellyn

Method toString() of Class ThreeDPoint

• Method toString() makes use of its Object inherited method getClass() in displaying its debugging (String) representation.

//toString(): conversion facilitator public String toString(){ int a = (int)getX(); int b = (int)getY(); int c = (int)getZ();

return getClass() + “[“ + a + “,” + b + “,” + “,” + c + “]”;}

Casts are necessary as Point accessors return the int-valued

data fields as double values.

Page 33: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 33 © Mark Llewellyn

Method toString() of Class ThreeDPoint (cont.)

• Method getClass() returns a String description of the object’s type. For example, the following code segment:

• Displays:

ThreeDPoint c = new ThreeDPoint();System.out.println(c);

class geometry.ThreeDPoint(0,0,0);

Page 34: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 34 © Mark Llewellyn

//equals(): equality facilitator public boolean equals(Object v){ if (v instanceof ThreeDPoint){ ThreeDPoint p = (ThreeDPoint) v; int z1 = (int) getZ(); int z2 = (int) p.getZ(); return super.equals(p) && (z1 == z2); } else { return false; } }

Method equals() of Class ThreeDPoint

• ThreeDPoint method equals() uses superclass method equals() in determining whether parameter v is the same as the this object.

Invocation of superclass method equals().

special syntax required

Page 35: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 35 © Mark Llewellyn

Method equals() of Class ThreeDPoint (cont.)

• For the ThreeDPoint method equals() to use its superclass Point method equals(), a special syntax is required.

– The special syntax is required because by default the subclass version overrides normal access to the superclass version.

• Using the keyword super indicates explicitly that the superclass member is to be referenced.

Page 36: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 36 © Mark Llewellyn

//translate(): shifting facilitator public void translate(int deltax, int deltay, int deltaz){ translate(deltax, deltay); int zValue = (int)getZ(); setZ(zValue+deltaz); }

Method translate() of Class ThreeDPoint

• ThreeDPoint method translate() uses the superclass method translate() to assist in the shifting of position. However, the keyword super is not required to invoke the superclass translate() method because the superclass version uses two parameters and the subclass version uses three parameters.

• Java can determine from context that it is the superclass method translate() that is being invoked.

Because there are two parameters present, it is the

superclass method translate() being invoked.

Page 37: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 37 © Mark Llewellyn

ThreeDPoint c = new ThreeDPoint();c.translate(2,2,2);ThreeDPoint d = new ThreeDPoint(1,2,3);ThreeDPoint e = (ThreeDPoint) d.clone();System.out.println(c);System.out.println(d);System.out.println(e);System.out.println(d.equals(c));System.out.println(d.equals(e));

Using the Class ThreeDPoint• The following code segment illustrates some of the uses of the

class ThreeDPoint.

• This code segment produces the output:class.geometry.ThreeDPoint[2,2,2]class.geometry.ThreeDPoint[1,2,3]class.geometry.ThreeDPoint[1,2,3]falsetrue

Page 38: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 38 © Mark Llewellyn

Another Extension of the Point Class• Suppose an application calls for the use of colored points. For

example, we can use colored points to represent the pixels of some image. Once again the principle of inheritance can be used to create a class to represent colored points.

• As we did with the class ThreeDPoint, we’ll extend the Point class in a natural manner to provide a representation of a colored point. We’ll define a class called ColoredPoint.

• The class will add a data field color to represent the color attribute and an appropriate accessor and mutator for that property.

• The class will also need to provide overrides for equals(), clone(), and toString().

Page 39: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 39 © Mark Llewellyn

The ColoredPoint Class

//representation of a colored 2-d pointpackage geometry;import java.awt.*;

public class ColoredPoint extends Point{ //instance variable Color color;

//ColoredPoint(): default constructor public ColoredPoint(){ super();

setColor(Color, blue); //default color }

//ColoredPoint(): specific constructor public ColoredPoint(int a, int b, Color c){ super(a,b); setColor(c); }

Page 40: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 40 © Mark Llewellyn

//getColor(): color property accessor public Color getColor(){ return color;

} //setColor(): color property mutator public void setColor(Color c){ color = c; }

//toString(): string representation facilitator public String toString(){ int a = (int)getX(); int b = (int)getY(); Color c = getColor();

return getClass() + “[“ + a + “,” + b + “,” + “,” + c + “]”;}

Page 41: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 41 © Mark Llewellyn

//equals(): equality facilitator public boolean equals(Object v){ if (v instanceof ColoredPoint){ Color c1 = getColor(); Color c2 = ((ColoredPoint) v).getColor();

return super.equals(v) && c1.equals(c2); } else { return false; } }

//clone(): cloning facilitator public Object clone(){ int a = (int) getX(); int b = (int) getY(); Color c = getColor(); return new ColoredPoint(a,b,c); }}//end class ColoredPoint

Page 42: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 42 © Mark Llewellyn

Using the Class ColoredPoint• The following code segment illustrates some of the uses of the

class ColoredPoint.

• This code segment produces the output:

ColoredPoint c = new ColoredPoint();ColoredPoint d = new ColoredPoint(1,2, Color.Black);ColoredPoint e = (ColoredPoint) d.clone();System.out.println(c);System.out.println(d);System.out.println(e);System.out.println(d.equals(c));System.out.println(d.equals(e));

class.geometry.ColoredPoint[0,0,java.awt.Color[r=0,g=0,b=255]]class.geometry.ColoredPoint[1,2,java.awt.Color[r=0,g=0,b=0]]class.geometry.ColoredPoint[1,2,java.awt.Color[r=0,g=0,b=0]]falsetrue

Page 43: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 43 © Mark Llewellyn

Single Inheritance versus Multiple Inheritance

• Suppose an application calls for the use of colored, 3-dimensional points. The question is whether you can create a class Colored3DPoint that extends from both ThreeDPoint and ColoredPoint?

– The answer in Java is no.

• Java supports single inheritance, it does not support multiple inheritance.

• Due to the complex nature of multiple inheritance, the designers of Java decided explicitly not to support multiple inheritance.

Page 44: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 44 © Mark Llewellyn

Problems of Multiple Inheritance• To illustrate a fundamental problem with multiple

inheritance consider the following situation.

– Suppose we were to create a class Colored3DPoint by extending it from both ThreeDPoint and ColoredPoint. Should the new class have two sets of x- and y- coordinate values because ThreeDPoint and ColoredPoint both have x- and y- coordinate values? On the other hand, should it have one set of x- and y- coordinate values because ThreeDPoint and ColoredPoint are both extended from Point?

• Rather than force programmers to deal with situations like the one described above, Java does not permit multiple inheritance.

Page 45: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 45 © Mark Llewellyn

Problems of Multiple Inheritance (cont.)

• Thus, if we want to define a class Colored3DPoint, we would need to do one of the following:

1. Extend ThreeDPoint to provide a color attribute. In this case Colored3DPoint becomes a subclass of ThreeDPoint which is already a subclass of Point. This case is illustrated by the code which begins on the next page.

2. Extend ColoredPoint to provide a z- coordinate attribute. In this case Colored3DPoint becomes a subclass of ColoredPoint which is already a subclass of Point. You should try this extension yourself to become more familiar with inheritance in Java.

Page 46: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 46 © Mark Llewellyn

The Colored3DPoint Class

//representation of a colored 3-d pointpackage geometry;import java.awt.*;

public class Colored3DPoint extends ThreeDPoint{ //instance variable Color color;

//Colored3DPoint(): default constructor public Colored3DPoint(){ super();

setColor(Color, blue); //default color }

//Colored3DPoint(): specific constructor public Colored3DPoint(int a, int b, int c, Color d){ super(a,b,c); setColor(d); }

Page 47: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 47 © Mark Llewellyn

//getColor(): color property accessor public Color getColor(){ return color;

} //setColor(): color property mutator public void setColor(Color c){ color = c; }

//toString(): string representation facilitator public String toString(){ int a = (int)getX(); int b = (int)getY(); int c = (int)getZ(); Color d = getColor();

return getClass() + “[“ + a + “,” + b + “,” + “,” + c + “,” + d +“]”;}

Page 48: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 48 © Mark Llewellyn

//equals(): equality facilitator public boolean equals(Object v){ if (v instanceof Colored3DPoint){ Color c1 = getColor(); Color c2 = ((Colored3DPoint) v).getColor();

return super.equals(v) && c1.equals(c2); } else { return false; } }

//clone(): cloning facilitator public Object clone(){ int a = (int) getX(); int b = (int) getY(); int c = (int) getZ(); Color d = getColor(); return new Colored3DPoint(a,b,c,d); }}//end class Colored3DPoint

Page 49: COP 3330: Object-Oriented Programming Summer 2007 Inheritance and Polymorphism – Part 1

COP 3330: Inheritance Page 49 © Mark Llewellyn

Why Not Add To Classes Rather Than Extend Classes?

• Why bother with inheritance at all? Why not just modify the existing class to include the new features? For example, why not give the Point class a z-coordinate value?

– Simply adding features can make a class too complex to understand or build. Imagine if such an approach were taken in the construction of a car from our earlier example. Our car class would be too unwieldy to use effectively.

– Another factor that should discourage adding to a class is user confidence and cost. Complex classes are difficult to build, maintain, and test. Programmers are understandably skeptical regarding the use of a massive API. Furthermore, if the source code to an existing class is not available, then adding new features to that class is not an option. Most libraries are distributed as compressed archives or as .class files with .java versions unavailable – developers often keep the .java versions to themselves to protect their intellectual investment.