1. Chapter 8
Inheritance
Part 2

2. Outline Creating Subclasses Overriding Methods Class Hierarchies
Inheritance and Visibility
Designing for Inheritance
© 2004 Pearson Addison-Wesley. All rights reserved

3. Class Hierarchies
A child class of one parent can be the parent of another child, forming a class hierarchy
Business
KMart
Macys
ServiceBusiness
Kinkos
RetailBusiness
© 2004 Pearson Addison-Wesley. All rights reserved

4. Class Hierarchies Two children of the same parent are called siblings
 Common features should be put as high in the hierarchy as is reasonable
An inherited member is passed continually down the line
Therefore, a child class inherits from all its ancestor classes
There is no single class hierarchy that is appropriate for all situations
© 2004 Pearson Addison-Wesley. All rights reserved

5. The Object Class
A class called Object is defined in the java.lang package of the Java standard class library
 All classes are derived from the Object class
Look at your JavaDoc to see the inheritance!
If a class is not explicitly defined to be the child of an existing class, it is assumed to be the child of the Object class
Therefore, the Object class is the ultimate root of all class hierarchies
© 2004 Pearson Addison-Wesley. All rights reserved

6. The Object Class – Example: to String
The Object class contains a few useful methods, which are inherited by all classes
For example, the toString method is defined in the Object class
Every time we define ‘our own’ toString method, we are actually overriding an inherited definition. We have done this repeatedly in objects for which we want ‘certain’ attributes displayed simply by printing the object-only name.
So what happens if we System.out.println(objName) and don’t have a toString method in that object? Try it!
The toString method in the Object class is defined to return a string containing the name of the object’s class along with other information. Normally, when we print objects (the way we have) we override this default and code our ‘own’ toString method for a specific object.
© 2004 Pearson Addison-Wesley. All rights reserved

7.  The Object Class – Example: equals
The equals method of the Object class returns true (Boolean) if two references are aliases (contain the same address)
We can (and very often do) override equals in any class to define equality in some more appropriate way
As we've seen, the String class defines the equals method to return true if two String objects contain the same characters!
The designers of the String class have overridden the equals method inherited from Object in favor of a more useful version that we normally use in comparing Strings.
Consequently, we use the overridden format with: int equals (object1.equals(object2))
© 2004 Pearson Addison-Wesley. All rights reserved

8. Abstract Classes
An abstract class is a placeholder in a class hierarchy that represents a generic concept
 An abstract class cannot be instantiated
We use the modifier abstract on the class header to declare a class as abstract:
public abstract class Product {
// contents }
© 2004 Pearson Addison-Wesley. All rights reserved

9. Abstract Classes
An abstract class often contains abstract methods with no definitions (like an interface)
 Unlike an interface, the abstract modifier must be ap plied to each abstract method because:
an abstract class typically contains non-abstract methods with full definitions. So abstract definitions must be clearly defined.
This means that some of its methods may be abstract and some may be concrete – unlike an interface in which ALL methods must be abstract and we DON’T have to tag the class as abstract (rather we use ‘interface’).
A class declared as abstract does not have to contain abstract methods -- simply declaring it as abstract makes it so.
(It may be that we plan on overriding its methods later…and we want a placeholder.)
© 2004 Pearson Addison-Wesley. All rights reserved

10. Abstract Classes
The child of an abstract class must override all the abstract methods of the parent, or it too will be considered abstract
So, if an abstract class contains both abstract methods as well as concrete methods, all the abstract ones must be overridden by a child, unless it too is to be abstract.
An abstract method cannot be defined as final or static, because it could not then be overridden.
 The use of abstract classes is an important element of software design – it allows us to establish common elements in a hierarchy that are too generic to instantiate
© 2004 Pearson Addison-Wesley. All rights reserved

11. {abstract} Geometric Figure
{abstract} int draw() ;
class Rectangle
draw()
class Circle
draw()
Class Trapezoid
draw()
© 2004 Pearson Addison-Wesley. All rights reserved

12. Interface Hierarchies – not a Class Hierarchy
 Inheritance can be applied to interfaces as well as classes; that is, one interface can be derived from another interface
The child interface inherits all abstract methods of the parent. (Can add more too…)
of course, other than constants, that’s all that’s in an interface.
 A class implementing the child interface must, then, define all methods from both the ancestor and child interfaces
Note that class hierarchies and interface hierarchies are distinct (they do not overlap)
© 2004 Pearson Addison-Wesley. All rights reserved

13. Outline Creating Subclasses Overriding Methods Class Hierarchies
Inheritance and Visibility
Designing for Inheritance
© 2004 Pearson Addison-Wesley. All rights reserved

14. Visibility Revisited
It's important to understand one subtle issue related to inheritance and visibility
 All variables and methods of a parent class, even private members, are inherited by its children
As we've mentioned, private members cannot be referenced by name in the child class
However, private members inherited by child classes exist and can be referenced indirectly through the methods of the parent.
© 2004 Pearson Addison-Wesley. All rights reserved

15. Visibility Revisited
The parent can refer to its own private member directly (of course); the child can reference it indirectly using its parent's methods
The super reference can be used to refer to the parent class, even if no object of the parent exists
Let’s look at three classes.
© 2004 Pearson Addison-Wesley. All rights reserved

16. //********************************************************************
// FoodAnalyzer.java Author: Lewis/Loftus //
// Demonstrates indirect access to inherited private members.
public class FoodAnalyzer { //
// Instantiates a Pizza object and prints its calories per
// serving.
public static void main (String[] args)
Pizza special = new Pizza (275); // creating an object of type Pizza
// with an argument passed to its
// Constructor.
System.out.println ("Calories per serving: " + special.caloriesPerServing());
// presumably, method is in Pizza (or inherited…)
} // end main()
} // end FoodAnalyzer
© 2004 Pearson Addison-Wesley. All rights reserved

17. //********************************************************************
// Pizza.java Author: Lewis/Loftus //
// Represents a pizza, which is a food item. Used to demonstrate
// indirect referencing through inheritance.
public class Pizza extends FoodItem  Inherits from FoodItem { //
// Sets up a pizza with the specified amount of fat (assumes
// eight servings).
public Pizza (int fatGrams)
super (fatGrams, 8);
// fatGrams is private in parent, but it is still inherited.
// Get to it via ‘super’. If ‘protected’ could access directly.
// Note also: no instance variables for any Pizza objects… }
// Note: caloriesPerServing() is NOT HERE. Thus it MUST be inherited.
// Let’s see the base class.
© 2004 Pearson Addison-Wesley. All rights reserved

18. public class FoodItem // servings (a protected variable).
// FoodItem.java Author: Lewis/Loftus // Base Class
// Represents an item of food. Used as parent of derived class to demonstrate indirect referencing.
public class FoodItem {
final private int CALORIES_PER_GRAM = 9;
private int fatGrams;
protected int servings;
// Sets up this food item with the specified number of fat grams
public FoodItem (int numFatGrams, int numServings)
fatGrams = numFatGrams; // fatGrams is private. Can only access via methods
servings = numServings; // servings is protected; could access directly due to inheritance. }
// Computes and returns the number of calories in this food item due to fat.
private int calories()
return fatGrams * CALORIES_PER_GRAM;
// Computes and returns the number of fat calories per serving.
public int caloriesPerServing()
return (calories() / servings); //  this calls calories() (in same object) and divides by
// servings (a protected variable).
© 2004 Pearson Addison-Wesley. All rights reserved

19. Outline Creating Subclasses Overriding Methods Class Hierarchies
Inheritance and Visibility
Designing for Inheritance
© 2004 Pearson Addison-Wesley. All rights reserved

20. Designing for Inheritance
As we've discussed, taking the time to create a good software design reaps long-term benefits
Inheritance issues are an important part of an object-oriented design
Properly designed inheritance relationships can contribute greatly to the elegance, maintainabilty, and reuse of the software
Let's summarize some of the issues regarding inheritance that relate to a good software design
© 2004 Pearson Addison-Wesley. All rights reserved

21. Inheritance Design Issues
Every derivation should be an is-a relationship
Think about the potential future of a class hierarchy, and design classes to be reusable and flexible, and cohesive.
Find common characteristics of classes and push them as high in the class hierarchy as appropriate
Override methods as appropriate to tailor or change the functionality of a child
Add new variables to children, but don't redefine (shadow) inherited variables
© 2004 Pearson Addison-Wesley. All rights reserved

22. Inheritance Design Issues
 Allow each class to manage its own data;
 Use the super reference to invoke the parent's constructor to set up its data
 Even if there are no current uses for them, override general methods such as toString and equals with appropriate definitions
Use abstract classes to represent general concepts that lower classes have in common
Use visibility modifiers carefully to provide needed access without violating encapsulation
© 2004 Pearson Addison-Wesley. All rights reserved

23. Restricting Inheritance
The final modifier can be used to curtail inheritance
If the final modifier is applied to a method, then that method cannot be overridden in any descendent classes
If the final modifier is applied to an entire class, then that class cannot be used to derive any children at all
Thus, an abstract class cannot be declared as final
These are key design decisions, establishing that a method or class should be used as is
© 2004 Pearson Addison-Wesley. All rights reserved

24. Summary Chapter 8 focused on:
deriving new classes from existing classes
the protected modifier
creating class hierarchies
abstract classes
indirect visibility of inherited members
designing for inheritance
© 2004 Pearson Addison-Wesley. All rights reserved