1 / 22

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

Inheritance, part 3 Method overriding, virtual methods, abstract classes/methods. COMP 401, Spring 2014 Lecture 10 2/ 11/2014. Subclassing So Far. A subclass inherits implementation details from its superclass Fields Direct access to public and protected fields

cloris
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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()

More Related