CS 106Introduction to Computer Science I

04 / 11 / 2008

Instructor: Michael Eckmann

Inheritance

• If class A inherits from class B, then class A is a subclass of B and class B is a superclass of A. We also talk of class A as being class B's child and class B being class A's parent.

• We can draw the inheritance relationships hierarchy by having superclass(es) at the top and subclass(es) lower, using lines to connect where there's an inheritance relationship.

Inheritance

• Class A may inherit from class B which can in turn, inherit from class C. (draw on the board.)

• However, this is not considered multiple inheritance.

• Multiple inheritance is an object-oriented concept that allows a subclass to inherit from more than one class --- this is NOT allowed in Java.

• e.g. Class D cannot inherit from both class E and F directly. (draw on the board.)

Inheritance

• A subclass inherits all the instance variables in its superclass and has access to (can call) any public methods.

• Even if there is private instance data in a superclass, the subclass inherits that data but can't refer to the variables.

• e.g. a SavingsAccount will inherit accountNumber from Account, so an object of type SavingsAccount will have an accountNumber.

Object is the superclass of all• All classes inherit from Java's Object class.

• All classes that do not use the extends keyword directly inherit from Java's Object class.

• What does that mean for us?

• Let's visit the Java API for the Object class.

– equals()

– toString()

super• is a reference to the parent class

• super(); // is a call to the parent's default (no parameter) constructor

• A call to a parent constructor should be the first thing done in any constructor of a child.

• If you don't explicitly call it, Java will automatically call the parent's default constructor if it exists.

Bank account • We could create an Account class that contained the

common stuff among all accounts• We then could create a SavingsAccount class that inherits

all the stuff about an Account from Account class and adds the things that are specific to Savings Accounts.

• We also could create a CheckingAccount class that inherits all the stuff about an Account from Account class and adds the things that are specific to Checking Accounts.

• These ideas are Inheritance ideas

Bank account • Notice that the data here isn't for all accounts:

–Account number (for all accounts)

–Balance (for all accounts)

–Overdrawn Fee (for all accounts)

–ATM Withdrawal Per Day Limit (for all accounts)

–Bounced Check Fee (for checking accounts only)

– Interest Rate (for savings accounts only)

Hierarchy of the account classes

• SavingsAccount and CheckingAccount each inherit from Account

• What about AccountTester?

• How about the Object class?

Overriding methods• A subclass can override a superclass's method by providing a

definition for a method that exists in the superclass with the same name and number and type of parameters.

• Let's add a method to Account and override it in SavingsAccount, but not in CheckingAccount.

• Then let's call the method with an object of SavingsAccount.

• And let's call the method with an object of CheckingAccount.

Overriding methodspublic String toString()

• What do you think about the toString() method? Can that be overridden by Account?

• Can it be overridden by a subclass of Account, like SavingsAccount?

equals method• In class Object, the header for the equals method is this:

public boolean equals(Object obj)

• If we want to override this method, we must make sure our equals method has the SAME signature.

• Does anyone recall what a signature contains?

Good design principle• It should be apparent that in a case like the one we're doing now,

Bank Accounts, we don't ever want the data to be allowed to be invalid.

• Care must be taken to require that a class's variables cannot have invalid data at any time.

• e.g. We wouldn't want to allow ATM_Withdrawal_Per_Day_Limit to ever be negative. It doesn't make sense.

• Also, Account #'s typically have a valid range of possibilities. We certainly wouldn't want account_number to be public and therefore able to be changed to an invalid value.

• We make the appropriate instance variables private for just that reason. And then only allow them to be changed in a controlled way via methods with some testing in them.

• We could put some testing in the code to handle this.

Protected vs. Private vs. Public• subclasses have access to public and protected members of their superclass

• a class has access to all of its own members (whether they are private, protected or public)

• objects of a class have access only to the public members of the class (and the public members of the parent class(es)).

• Classes within the same package though are allowed to always access protected members --- but I don't recommend this.

•What does this mean for our Account program?

•What about inside the CheckingAccount class, what members of Account can we refer to?

•What about an object of type CheckingAccount --- does it have access to any of the members in Account?

Overloaded methods• Overloaded methods are those that have the same name but

different numbers or types of parameters.

• It has nothing to do with the super / subclass (parent / child) relationships that we've been talking about.

• Does anyone remember when we used Overloaded methods?

Account Program• Let's continue to implement Account, CheckingAccount,

SavingsAccount

– toString()

– equals(Object o)

– Add set methods, get methods

• Deposit, withdraw methods (instead of setBalance)

– Create objects

Abstract classes• Abstract classes

– Can never be instantiated

– Can contain both abstract methods and actual (non-abstract) methods

– Can contain instance variables as well as constants

• If a class contains any abstract methods then it MUST BE an abstract class

• But an abstract class is not required to have abstract methods

• Abstract classes are different from interfaces which we will see next.