King Fahd University of Petroleum & Minerals
College of Computer Science & Engineering
Information & Computer Science Department
ICS201
Lecture 3 : Inheritance III
Slides prepared by Rose Williams, Binghamton University
Access Modifiers [review]
Tip: "Is a" Versus "Has a"
A derived class demonstrates an "is a" relationship between it
and its base class
For example, an HourlyEmployee "is an" Employee
HourlyEmployee is a more complex class compared to the more
general Employee class
Tip: "Is a" Versus "Has a"
Another way to make a more complex class out of a simpler
class is through a "has a" relationship
This type of relationship, called composition, occurs when a class
contains an instance variable of a class type
The Employee class contains an instance variable, hireDate, of
the class Date, so therefore, an Employee "has a" Date
then HourlyEmployee "is an" Employee and "has a" Date
Tip: Static Variables Are Inherited
Static variables in a base class are inherited by any
of its derived classes
The modifiers public, private, and protected,
and package access have the same meaning for
static variables as they do for instance variables
Access to a Redefined Base Method
Within the definition of a method of a derived class,
the base class version of an overridden method of
the base class can still be invoked
Simply preface the method name with super and a dot :
public class HourlyEmployee extends Employee {
……
public String toString()
{
return (super.toString() + "$" + wageRate);
}
}
You Cannot Use Multiple supers
It is only valid to use super to invoke a method from a direct
parent
Repeating super will not invoke a method from some other
ancestor class
For example, if the Employee class were derived from the
class Person, and the HourlyEmployee class were derived
form the class Employee , it would not be possible to invoke
the toString method of the Person class within a method
of the HourlyEmployee class
super.super.toString() // ILLEGAL!
The Class “Object”
In Java, every class is a descendent of the class
Object
Every class has Object as its ancestor
Every object of every class is of type Object, as well as
being of the type of its own class
If a class is defined that is not explicitly a derived
class of another class, it is still automatically a
derived class of the class Object
The Class “Object”
The class Object is in the package java.lang which is
always imported automatically
Having an Object class enables methods to be written with a
parameter of type Object
A parameter of type Object can be replaced by an object of any
class whatsoever
The class Object has some methods that every Java class
inherits (e.g. the equals and toString methods)
Every object inherits these methods from some ancestor class
Either the class Object itself, or a class that itself inherited these
methods (ultimately) from the class Object
However, these inherited methods should be overridden with
definitions more appropriate to a given class
The Right Way to Define equals
Since the equals method is always inherited from the class
Object, methods like the following simply overload it:
Defined in the
public boolean equals(Employee otherEmployee) current class
{ . . . }
public boolean equals(Object otherObject)
{ . . . } Inherited from
class Object
However, the method inherited from class Object should be
overridden, not just overloaded. Why ?? .. See next slide
The Right Way to Define equals
public boolean equals(Object otherObject)
{ . . . }
The parameter otherObject of type Object must be type cast
to the given class (e.g., Employee)
However, the new method should only do this if otherObject
really is an object of that class, and if otherObject is not equal
to null
Finally, it should compare each of the instance variables of both
objects
A Better equals Method for the Class
Employee
public boolean equals(Object otherObject) To check that the
{ object is not null
if(otherObject == null)
return false;
else if(getClass( ) != otherObject.getClass( ))
return false; To check that the
else object is of the
{ right class
Employee otherEmployee = (Employee)otherObject;
return (name.equals(otherEmployee.name) &&
hireDate.equals(otherEmployee.hireDate));
}
} Check the equality
of instance
variables one by
one
Tip: getClass Versus instanceof
Many authors suggest using the instanceof
operator in the definition of equals
Instead of the getClass() method
The instanceof operator will return true if the
object being tested is a member of the class for
which it is being tested
However, it will return true if it is a descendent of that
class as well
It is possible (and especially disturbing), for the
equals method to behave inconsistently given this
scenario
Tip: getClass Versus instanceof
Here is an example using the class Employee
. . . //excerpt from bad equals method
else if(!(OtherObject instanceof Employee))
return false; . . .
Now consider the following:
Employee e = new Employee("Joe", new Date());
HourlyEmployee h = new
HourlyEmployee("Joe", new Date(),8.5, 40);
boolean testH = e.equals(h);
boolean testE = h.equals(e);
e and h are created from different classes. So both testH and testE
should be false. However, ..
Tip: getClass Versus instanceof
testH will be true, because h is an Employee
with the same name and hire date as e
However, testE will be false, because e is not an
HourlyEmployee, and cannot be compared to h
Note that this problem would not occur if the
getClass() method were used instead, as in the
previous equals method example
The instanceof Operator
The instanceof operator checks if an object is of
the type given as its second argument
Object instanceof ClassName
This will return true if Object is of type ClassName, and
otherwise return false
Note that this means it will return true if Object is the
type of any descendent class of ClassName
The getClass() Method
Every object inherits the same getClass() method
from the Object class
An invocation of getClass() on an object returns
a representation only of the class that was used with
new to create the object
The results of any two such invocations can be compared
with == or != to determine whether or not they represent
the exact same class
(object1.getClass() == object2.getClass())
The end
