chapter13

chapter13 - Chapter 13 Inheritance Goals To learn about...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Chapter 13 Inheritance Goals To learn about inheritance To understand how to inherit and override superclass methods To be able to invoke superclass constructors To learn about protected and package access control To understand the common superclass Object and to override its toString and equals methods Introduction In OOP languages, new classes can be derived from an existing class. Why? organizes related classes reduces code redundancy increases code reuse enables polymorphic references Inheritance: extend classes by adding methods and fields Example: Savings account is a bank account with interest Introduction class SavingsAccount extends BankAccount { new methods new instance fields } Introduction SavingsAccount automatically inherits all methods and instance fields of BankAccount SavingsAccount collegeFund = new SavingsAccount(10); // Savings account with 10% interest collegeFund.deposit(500); // OK to use BankAccount method with SavingsAccount // object Superclass / Subclass Original/base class is known as the superclass (BankAccount) extending class is the subclass (SavingsAccount) Every class extends the Object class either directly or indirectly Inheritance vs Interface Inheriting from an existing class IS NOT the same as implementing interface A subclass inherits behavior and state Interfaces have no state or defined behavior Code Reuse One advantage of inheritance is code reuse Not "reinventing the wheel" Already have a class that does some base functions, why not just build up on it deposit, withdraw, getBalance common among all accounts In subclass, specify added instance fields, added methods, and changed or overridden methods Inheritance takes care of what is common, you define what is different public class SavingsAccount extends BankAccount{ private double interestRate; public SavingsAccount(double rate) { interestRate = rate; } public void addInterest() { double interest = getBalance() * interestRate / 100; deposit(interest); } } Why do we call getBalance? Why not just use balance? double interest = getBalance() * interestRate / 100; Encapsulation Encapsulation: addInterest calls getBalance because balance field of the superclass is private Cannot access private members of another class Encapsulation SavingsAccount object inherits the balance instance field from BankAccount, and gains one additional instance field: interestRate Encapsulation Note that addInterest calls getBalance without specifying an implicit parameter (the calls apply to the same object) Means the call to is getBalance is applied to the same object as the object that called addInterest Syntax class SubclassName extends SuperclassName { extra instance fields extra methods } Inheritance Hierarchy Inheritance is a way to categorize In real world, categories often use hierarchies Generic items yield more specific items Bird Robin, Blue Jay, Cardinal, etc. Sets of classes can form complex inheritance hierarchies Inheritance Hierarchy What is the common set of features? Superclass There are all birds class Bird{...} ISA Hierarchy again What is at the top of every hierarchy? Example Consider a bank that offers its customers the following account types: Checking account: no interest; small number of free transactions per month, additional transactions are charged a small fee Savings account: earns interest that compounds monthly Example Example All bank accounts support the getBalance method All bank accounts support the deposit and withdraw methods, but the implementations differ Checking account needs a method deductFees; savings account needs a method addInterest Inheriting Instance Fields and Methods A subclass can define additional instance fields and methods With existing methods They can override definitions from the superclass They can inherit them as is Can also define new methods Overriding methods Supply a different implementation of a method that exists in the superclass Must have same signature (same name and same parameter types) If method is applied to an object of the subclass type, the overriding method is executed Inheriting methods Don't supply a new implementation of a method that exists in superclass Superclass method can be applied to the subclass objects with no additional work Adding methods Supply a new method that doesn't exist in the superclass New method can be applied only to subclass objects Inheriting Instance Fields Cannot override fields Inheriting fields: All fields from the superclass are automatically inherited Adding fields: Can supply a new field that doesn't exist in the superclass Inheriting Fields What if you define a new field with the same name as a superclass field? Each object would have two instance fields of the same name Fields can hold different values Legal but extremely undesirable CheckingAccount Class Overrides deposit and withdraw to increment the transaction count: public class CheckingAccount extends BankAccount { private int transactionCount; // new instance field public public public void void void deposit(double amount) { . . . } withdraw(double amount) { . . . } deductFees() { . . . } // new method } CheckingAccount Class Each CheckingAccount object has two instance fields: balance (inherited from BankAccount) transactionCount (new to CheckingAccount) CheckingAccount Class You can apply four methods to CheckingAccount objects: (Inherited from BankAccount) deposit(double amount) (overrides BankAccount method) withdraw(double amount) (overrides BankAccount method) deductFees() (new to CheckingAccount) getBalance() Inheriting Private Fields Consider deposit method of CheckingAccount public void deposit(double amount) { transactionCount++; // now add amount to balance ... } Inheriting Private Fields Consider deposit method of CheckingAccount public void deposit(double amount) { transactionCount++; // now add amount to balance balance = balance + amount; } Will this work? Inheriting Private Fields Can't just add amount to balance balance is a private field of the superclass A subclass has no access to private fields of its superclass So the subclass must use public interface Inheriting Private Fields Consider deposit method of CheckingAccount public void deposit(double amount) { transactionCount++; // now add amount to balance deposit(amount); } Will this work? Invoking a Superclass Method Can't just call deposit(amount) in the deposit method of CheckingAccount That is the same as this.deposit(amount) which calls the method on the CheckingAcccount object Calls the same method (infinite recursion) Invoking a Superclass Method Java allows you to specify calling a method of the superclass with the keyword super Invoke superclass method super.deposit(amount) Now calls deposit method of BankAccount class Example public void deposit(double amount) { transactionCount++; // Now add amount to balance super.deposit(amount); } Example public class CheckingAccount extends BankAccount { private static final int FREE_TRANSACTIONS = 3; private static final double TRANSACTION_FEE = 2.0; . . . public void withdraw(double amount) { transactionCount++; // Now subtract amount from balance super.withdraw(amount); } Example (Continued) public void deductFees() { if (transactionCount > FREE_TRANSACTIONS) { double fees = TRANSACTION_FEE * (transactionCount - FREE_TRANSACTIONS); super.withdraw(fees); } transactionCount = 0; } Object Class a class extends Object by default when no extends clause is used, e.g: class Thing { ... } is equivalent to class Thing extends Object { ... } Object Class belongs to java.lang package is the superclass of all other classes has several generic methods equals toString getClass clone Object Class Methods boolean equals ( Object obj ) returns true iff this object is alias of obj default: compares addresses String toString () returns a String representing this object default: <class name>@<hashcode> Inheritance and Constructors Unlike members and methods of a superclass, constructors of a superclass are not inherited by its subclasses. You must define a constructor for a subclass or use the default constructor added by the compiler. How do you initialize superclass fields? In SavingsAccount, how do we initialize balance? Inheritance and Constructors super(); Calls the default constructor of the superclass Analagous to this() Every constructor of a subclass must make a call to the superclass constructor. If you don't compiler will add in A call to super() MUST be the first line of code in the constructor Example public class CheckingAccount extends BankAccount { public CheckingAccount(double initialBalance) { super(initialBalance);// Construct superclass transactionCount = 0; // Init transaction ct } . . . } Inheritance and Constructors class MyClass { public MyClass(int x){ ... } } class SubClass extends MyClass{ //No Constructor } Won't compile default constructor of SubClass tries to call super(), but MyClass() is not defined Inheritance and Constructors If a class has a superclass that is not the Object class, then a constructor of the class should make an explicit call to a constructor of the superclass. Always provide a constructor for every class you define. Don't rely on default constructors. Example class MyClass { public MyClass(int x){ ... } } class SubClass extends MyClass{ public SubClass(){ super();//INVALID! } } Example class MyClass { public MyClass(int x){ ... } } class SubClass extends MyClass{ public SubClass(int y){ super(y);//VALID! } } Conversions Ok to convert subclass reference to superclass reference (think: BlueJay to Bird) SavingsAccount collegeFund = new SavingsAccount(10); BankAccount anAccount = collegeFund; Object anObject = collegeFund; Conversions Conversions Problem: superclass references don't know the full story: anAccount.deposit(1000); // OK anAccount.addInterest(); // No--not a method of the class to which anAccount belongs Why is this? Conversions Converting up to superclass leads to less information Why would we want this? Reuse code that uses superclass Conversions Reuse code that knows about the superclass but not the subclass: public void transfer(double amount, BankAccount other) { withdraw(amount); other.deposit(amount); } Conversions Already learned how to use this method to transfer from one BankAccount to another But we can also use it to transfer from one CheckingAccount to another! Polymorphism! The method doesn't know the difference, because it only needs to know that a CheckingAccount IS A BankAccount Super to Sub Conversion How do we convert down the chain BankAccount object CheckingAccount? Is this safe? We need a way to protect ourselves if we aren't sure... instanceOf Purpose: Check to see if an object is of a particular class Give: identifier and class Returns: boolean true if it is that type, false otherwise Convert from Super to Sub if (anObject instanceof { BankAccount anAccount . . . } BankAccount) = (BankAccount) anObject; Polymorphism In Ch.11, we learned that the type of the identifier (Measurable) does not have to match the type of the object (BankAccount, Coin) Inheritance demonstrates the same phenomenon A BankAccount identifier can be referring to a BankAccount, CheckingAccount, or SavingsAccount Polymorphism Which version of deposit is called? When is this determined? BankAccount anAccount = new CheckingAccount(); anAccount.deposit(1000); Polymorphism Method calls are always determined based on the type of the actual object being stored, not the type of the reference/identifier This ability to refer to multiple types with varying behavior is called polymorphism Polymorphism A limitation is that polymorphism only works if the reference type always has an implementation of that call Ex. Will the following work? Measurable x = new BankAccount(); x.deposit(500); Polymorphism Previously, we called deposit on a BankAccount object. When compiling, Java needs to know that a deposit method is legal to call on that object, not which method will be called Even though we didn't know which version would be called, we can be guaranteed that any object stored with a BankAccount reference can handle deposit Polymorphism If the method is specific to only one subclass, then the compiler can guarantee legality Object anObject = new BankAccount(); anObject.deposit(1000); // Compiling Error BankAccount ba = new CheckingAccount(); anObject.deductFees(); // Compiling Error Access Control Java has four levels of controlling access to fields, methods, and classes: public access Can be accessed by methods of all classes Can be accessed only by the methods of their own class private access Access Control protected access package access The class and all subclasses can access The default, when no access modifier is given Can be accessed by all classes in the same package Good default for classes, but extremely unfortunate for fields Recommended Access Levels Instance and static fields: Always private. Exceptions: safe Some objects, such as System.out, need to be accessible to all programs (public) Occasionally, classes in a package must collaborate very closely (give some fields package access); inner classes are usually better Can be protected also... public static final constants are useful and Recommend Access Methods: public or private Classes and interfaces: public or package Override (redefine) We can override public and protected data members and methods of any superclass Use the same signature to override an inherited method. Recall that everything inherits from Object What comes in this class? Some useful methods: Object: The Cosmic Superclass String toString() boolean equals(Object otherObject) Object clone() Do these work well as defined? NO! Good idea to override these methods toString() Going to concentrate on the toString method Returns a string representation of the object Useful for debugging: Rectangle box = new Rectangle(5, 10, 20, 30); String s = box.toString(); // Sets s to // "java.awt.Rectangle[x=5,y=10,width=20,height=30]" toString() Unlike other methods, toString() can actually be called implicitly Concatenation Calling "box = " + box; print() or println() System.out.println(box); How can the compiler know to do this? Because every object has a toString method through Inheritance polymorphism toString() The Object class definition returns the object and a hashcode (identifier) BankAccount momsSavings = new BankAccount(5000); String s = momsSavings.toString(); // Sets s to something like "BankAccount@d24606bf" Pretty boring... toString() We can override the definition of any inherited method! What methods did we do this on before? Usually want to know what's inside the object (fields, etc) Print name of class, then the values of instance fields in brackets toString() public String toString() { return "BankAccount[balance=" + balance + "]"; } toString() Now this works better: BankAccount momsSavings = new BankAccount(5000); String s = momsSavings.toString(); // Sets s to "BankAccount[balance=5000]" toString() toString is a little harder with subclasses How do we make BankAccount toString work for any subclasses? Use getClass() method public String toString() { return getClass().getName() + "[balance=" + balance + "]"; } ...
View Full Document

Ask a homework question - tutors are online