Inheritance, part 3 Method overriding, virtual methods, abstract classes/methods

1. Inheritance, part 3Method overriding, virtual methods, abstract classes/methods COMP 401, Spring 2014 Lecture 10 2/11/2014

2. Subclassing So Far • A subclass inherits implementation details from its superclass • Fields • Direct access to public and protected fields • No direct access to private fields • Methods • Access to public and protected methods • No access to private methods • Subclass constructors • Should call superclass constructor with super() as first line. • Or, chain to a different constructor • Or, rely on implicit call to super() constructor with no parameters.

3. Subclass Method Polymorphism • Subclass can overload methods in superclass. • Remember, overloading is providing a different version of an existing method. • An example of polymorphism • Method signature is different in some way. • lec10ex1

4. Overriding Methods • A subclass can “override” a super class method by providing its own definition. • Method signature must be the same. • Original method is visible from subclass • i.e., public, protected, or package-level access • lec10ex2

5. @Override directive • So what’s with the funny “@Override” line that Eclipse includes when generating a stub? • Known as a compiler “directive”. • Completely optional, but useful • Indicates that the method is intended to override a superclass method. • Compiler will complain if it does not detect a visible superclass method with the same method signature. • Helpful when you misspell a method name or attempt to override a method not visible to the subclass. • lec10ex3

6. Class Polymorphism • Previously introduced the idea of “is-a” relationships • Between a class and interfaces implemented. • Between a class and its superclass hierarchy. • This is also an example of polymorphism • Covariance • Treating an instance of a subclass as a reference typed as the parent class. • This can be typed checked at compile type. • Contravariance • Treating a reference typed as the parent class as an instance of a subclass. • Contravariance can not be type checked in advance at compile time. • Fails if the object is actually “invariant” with respect to the subclass. • lec10ex4, lec10ex4main • Also demonstrates protected base class constructor

7. A Covariant Conundrum • Problem: • What should happen when an overridden method is called on a covariant reference? class A { public int m() {return 0;} } class B extends A { public int m() {return 1;} } class C extends B { public int m() {return 2;} } C c_obj = new C(); B b_obj = (B) c_obj; A a_obj = (A) c_obj; System.out.println(c_obj.m()); System.out.println(b_obj.m()); System.out.println(a_obj.m()); What should these lines print?

8. Solution 1: Non-virtual methods • Let type of reference dictate which method definition is used. class A { public int m() {return 0;} } class B extends A { public int m() {return 1;} } class C extends B { public int m() {return 2;} } C c_obj = new C(); B b_obj = (B) c_obj; A a_obj = (A) c_obj; System.out.println(c_obj.m()); System.out.println(b_obj.m()); System.out.println(a_obj.m()); If methods are non-virtual then these lines expected to print: 2 1 0

9. Solution 2: Virtual methods • Use method defined by the actual type of object (even if reference is covariant) class A { public int m() {return 0;} } class B extends A { public int m() {return 1;} } class C extends B { public int m() {return 2;} } C c_obj = new C(); B b_obj = (B) c_obj; A a_obj = (A) c_obj; System.out.println(c_obj.m()); System.out.println(b_obj.m()); System.out.println(a_obj.m()); With virtual methods, these lines expected to print: 2 2 2

10. Virtual Methods • Different OOP languages choose to solve this problem in different ways. • C++, C# • Default is non-virtual solution. • Programmer can force virtual solution by marking a method with a special “virtual” keyword • Java • Methods are always virtual. • No special keyword needed. • lec10ex5

11. A virtual problem • Drawback to the “always virtual” approach. • Consider the situation in which a subclass just needs a method to “do just a little more”. • In other words, wants to execute a method as defined in the superclass and then tweak the result. • Or maybe do something in advance of executing a method as defined in the superclass. • Because methods are always virtual, casting this reference to superclass in order to get to method as defined by the superclass won’t work. • lec10ex6

12. It’s a bird, it’s a plane, it’s… • … the super keyword. • The super keyword provides exactly this ability to invoke methods on an instance as it is understood at the superclass. • Think of it as a version to “this” that is restricted to just what is provided by the superclass. • Note: Only goes up one level in class hierarchy • Essentially suspending “virtualness” of methods. • lec10ex7

13. Whence inheritance • Related classes with common internals • Note, not just common behavior • Specialization after the fact of existing classes

14. Inheritance Recap • Subinterfacing • Adding methods to create a new “contract” • Subclassing • Inherits fields and methods from parent class • Visibility controlled by access modifier • Adds subclass specific fields and methods • Constructor relationship • Overloading parent methods • Subclass methods with different signatures than in parent class. • Overriding parent methods • Subclass methods with same signature as in parent class. • Always virtual • super keyword provides a mechanism to call parent class version of a method

15. Using inheritance • Example starts with several related classes that are implemented independently. • BlackBear • PolarBear • Python • Robin • lec10ex8.v1

16. Common behavior • Refactor common behaviors into a common parent interface. • Animal interface • lec10ex8.v2

17. Common object state • Refactor common object fields into a common parent class • AnimalImpl • Pull common fields id and location to here • Need to make protected in order to allow subclass access. • lec10ex8.v3

18. Common implementation • Refactor common method implementations into parent class. • Use overriding if subclasses need to do something special or different. • AnimalImpl • Constructor in parent class used by subclass constructor to initialize common fields at this level. • getID() and getLocation() moved here • Common portion of move() put here • Subclass-specific override of move • Calls common portion through super keyword • lec10ex8.v4

19. Common behavior with uncommon implementation • Notice speak() is a common behavior. • So we want it to be part of Animal interface • That way if we can have a reference to an Animal object and ask it to speak() without having to know what it’s subclass is. • But no common implementation. • Each subclass of animal will have a different way of speaking. • No good default or commonalities in way of speaking that can be specified at parent class.

20. Abstract Classes and Methods • Parent class has no meaningful implementation of a method. • But part of interface of parent class • Expect subclass to provide it. • In these situations, we never expect (or want) the parent class to be instantiated directly. • We always make new objects using a subclass. • Syntax • Use “abstract” modifier when declaring parent class • Declare any methods that must be provided by subclass in parent • Add “abstract” modifier to method signature. • Follow signature with semicolon instead of method definition

21. Example Revisited • AnimalImpl • Declare implementation of Animal here where it belongs since AnimalImpl is matching implementation. • Declare AnimalImpl as abstract • Prevents direct instantiation • Declare speak() method as abstract • No common implementation, but needs to be declared here as part of common interface. • Declaring as abstract forces subclass to override. • lec10ex8.v5

22. Repeat Exercise with Bears • lec10ex8.v6 • Draws out common bear behavior into Bear interface and common bear implementation in BearImpl • Bear extends Animal • Adds getColor() • BearImpl extends AnimalImpl • Provides lumber(), trek(), move(), and speak(). • Declared abstract because subclass must provide getColor()