CS 106 Introduction to Computer Science I 04 / 13 / 2007 Friday the 13 th Instructor: Michael Eckmann

Michael Eckmann - Skidmore College - CS Spring 2007 Today’s Topics questions, comments? suggested work More inheritance Allowable inheritance hierarchies Object class

Michael Eckmann - Skidmore College - CS Spring 2007 Suggested Work I suggest to those of you who need review of the recent material (if you do this you get 3 days extension to hand in program 2.) –I'll provide a solution to the last lab tonight –a) compare my solution to yours and examine what you don't understand and if after some work you have some questions, type them up. –b) without referring to my lab solution nor your last lab do an exercise I will send out via tonight –c) set up a meeting with me (I'll set aside this Wednesday evening for meetings) via to discuss the issues you don't understand.

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 directly --- this is NOT allowed in Java. e.g. Class D cannot inherit from both class E and F directly. (draw on the board.)

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 Exercise What data members describe a bank account? – That is, what does a bank account have. What types are these? We want to handle Checking and Savings Accounts

Bank account Maybe we might want the following data members: – Account number – Balance – Overdrawn Fee – ATM Withdrawal Per Day Limit – Bounced Check Fee – Interest Rate – Most recent withdrawal

Bank account So we could have a class named BankAccount that contains the following data: String account_number; double balance; double overdrawn_Fee; int ATM_Withdrawal_Per_Day_Limit; double bounced_Check_Fee; double interest_Rate; double most_recent_wd;

Bank account What methods might we need?

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) – Most recent withdrawal (for all accounts)

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 Inheritence ideas

Hierarchy of the account classes SavingsAccount and CheckingAccount each inherit from Account What about AccountTester? How about the Object class?

Account Program Let's implement Account, CheckingAccount, SavingsAccount – toString() – Add constructors that take in an account # Call super(acctnum) – Add set methods, get methods Deposit, withdraw methods (instead of setBalance) – Create objects

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'll 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 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 if CheckingAccount class wanted to refer to the most_recent_wd member or type_of_acct member? What about an object of type CheckingAccount --- does it have access to any of the members in Account?

Overriding methods A subclass can override a superclass's method by providing a definition for a method 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 methods 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?

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?