1 / 29

Object-Oriented Programming Part 2 Bank Account Exercise

Learn about Bank Account Exercise in Object-Oriented Programming. Explore solutions using inheritance and Java programming. Workshop held at Hood College on February 26, 2005.

drichmond
Download Presentation

Object-Oriented Programming Part 2 Bank Account Exercise

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. Hood College JETT Workshop Dept. of Computer Science February 26 2005 Object-Oriented ProgrammingPart 2Bank Account Exercise

  2. Object-Oriented ProgrammingPart 2 This presentation will cover: • Statement of Bank Problem • Proposed Solutions • Inheritance • BankAcct class • CheckAcct class • SavAcct class 2

  3. Bank Problem • Problem: Hood National Bank has hired you to develop banking software. Currently, the bank has several types of bank accounts (checking, savings, CD, money market, etc.) Write a program that will satisfy your customer’s needs. 3

  4. Disadvantage: A lot of the code is apt to be very similar. For instance, all classes contain instance fields acctName and balance, and method getAcctNo() and getBalance(). This code would have to be duplicated for each type of account! If the bank offers new types of accounts in the future, then every software application (including the one you’re currently writing) must be updated with the new type of account. Maintenance nightmare. Proposed Solution Here’s one possible approach: Create a class for each type of bank account: class CheckAcct { .. } class SavAcct { .. } class MMAcct { .. } 4

  5. Another Proposed Solution Create a master class Acct that accommodates all account types: public class Acct { private double balance; private String acctNo; private int type; // 1=Chkng. 2=Svng. 3=MM. private double intRate; // needed for Svng, MM private double minBal; // needed for MM .. public void withdraw(double amt) { if (type == 0) { .. } else if (type == 1) } .. } } 5

  6. Another Proposed Solution (cont’d) Advantage: • Some duplicated code can now be avoided. Disadvantages: • Since the master class Acct must accommodate any type of account, it has an excess of instance fields. An instance field must be included even if only one type of account needs it. • A maintenance problem still exists. If, in the future, the bank decides to offer new types of accounts, then the Account class must be updated with the new type of account. 6

  7. Best solution The solution in Java is to use inheritance.

  8. Inheritance BankAcct has two child classes (or subclasses) SavingAcct and CheckAcct. At the top of the hierarchy, the class BankAcct serves as a parent class (or base class or super class). The SavingAcct class in turn has one child: MMAcct. 8

  9. Inheritance Roughly, the inheritance diagram can be coded in Java as follows: public abstract class BankAcct { .. } public class SavAcct extends BankAcct { .. } public class CheckAcct extends BankAcct { .. } public class MMAcct extends SavAcct { .. } 9

  10. A child class “inherits” all of the methods and instance fields from the parent class. It is as if all of the public methods from the parent class were copied and pasted into the child class! This results in less code duplication. To indicate that one class is a subclass of another we use the keyword extends; e.g. public class MMAct extends SavAcct Inheritance (cont’d) • Each generation is related to the previous one via an “is-a” relationship. • A savings account and a checking account “is-a” bank account. • A Money Market account “is-a” savings account. 10

  11. Instance Variables Data Type Access acctNo balance String double private private Method Parameters Return Type Comment BankAcct() String acct double bal none constructor getBalance() none double getAcctNo() none String deposit() double amt void withdraw() double amt void BankAcct Class The base class BankAcct is a very simple one. 11

  12. CheckAcct Class • The CheckAcct class will automatically inherit the instance fields acctNo and balance from the parent class BankAcct. • The CheckAcct class will automatically inherit the methods deposit() and withdraw() from BankAcct. • However, although the inherited deposit() method will work correctly, the inherited withdraw() method will not! A withdrawal will affect the state of a CheckAcct object since doing so will decrease the instance field balance by an additional 50 cents. In this case, we must override the definition of withdraw(). 12

  13. Instance Variables Data Type Comment acctNo balance String double inherited inherited Method Parameter ReturnType Comment CheckAcct String acct double bal none constructor getBalance() none double inherited getAcctNo() none String inherited deposit() double amt void inherited withdraw() double amt void override CheckAcct Class (cont’d) 13

  14. CheckAcct Class (cont’d) public class CheckAcct { // Constructor public CheckAcct(String acct, double bal) { .. } // overrides withdraw() public void withdraw(double amt) { .. } // other methods and instance fields are inherited } 14

  15. CheckAcct Class (cont’d) • First, we override the withdraw() method. Here is a first attempt: // First attempt public void withdraw(double amt) { balance = balance – amt; balance = balance – 0.5; } The above, however, won’t compile! The reason is because the instance field balance is marked private in class BankAcct. This means that balance can be accessed only from non-static methods of BankAcct. Since the withdraw() method above is a method of CheckAcct(andnot BankAcct), balance is inaccessible. 15

  16. CheckAcct Class (cont’d) • Here’s a second attempt to override the withdrawal() method: // second attempt public void withdraw(double amt) { withdraw(amt); withdraw(0.50); } Exercise: Why won’t the above work? withdraw will call the CheckAcct withdraw method, create an infinite recursive loop. 16

  17. CheckAcct Class (cont’d) • Here’s our third and final (and correct) attempt: // third attempt public void withdraw(double amt) { super.withdraw(amt); super.withdraw(0.50); } The keyword super is a reference to the activating object’s superclass. Think of it as a pronoun that says, “My parent”. 17

  18. CheckAcct Class (cont’d) Finally, we define the constructor for CheckAcct class. In the constructor, we simply want to initialize the acctNo and balance as appropriate. Our first attempt looks like this: public CheckAcct(String acct, double bal) { acctNo = acct; balance = bal; } Exercise: Unfortunately, this won’t work! Why? acctNo and balance are private variables of the super class 18

  19. CheckAcct Class (cont’d) Here’s the correct version of the constructor: public CheckAcct(String acct, double bal) { super(acct, bal); } As before, the super keyword is a pronoun for “activating object’s parent.” In this context, the super keyword is used to invoke the activating object’s parent’s constructor, i.e. BankAcct’s constructor. 19

  20. CheckAcct Class (cont’d) Here’s what the CheckAcct class looks like: public class CheckAcct extends BankAcct { // constructor public CheckAcct(String acct, double bal) { super(acct, bal); } // overrides withdraw() public void withdraw(double amt) { super.withdraw(amt); super.withdraw(0.50); } // other methods and instance fields are inherited } 20

  21. SavAcct Class • Will automatically inherit the instance field acctNo and balance from the parent class BankAcct. • Requires two additional instance fields: the interest rate, intRate; and the lowest balance during the compounding period, lowBal. • Will automatically inherit the method deposit() and withdraw() from BankAcct. • However, although the inherited deposit() method will work correctly, the inherited withdraw() method will not! A withdrawal will affect the state of a SavAcct object since it affects the lowest balance. As with the CheckAcct class, we must override the definition of withdraw(). • The class SavAcct will also require a method addInt(), which adds interest to the account. 21

  22. Instance Variables Data Type Comment acctNo Balance intRate lowBal String double double double inherited inherited private private Method Parameter Return Type Comment SavAcct String acct double bal double rate none constructor getBalance() none double inherited getAcctNo() none String inherited deposit() double amt void inherited withdraw() double amt void override addInt() none void new method SavAcct Class (cont’d) 22

  23. SavAcct Class (cont’d) Here’s the constructor: public SavAcct(String acct, double bal, double rate) super(acct, bal); intRate = rate; lowBal = bal; } The method call super() means “call the constructor from the super class”, in this case, BankAcct. 23

  24. SavAcct Class (cont’d) Exercise: Write the withdraw() method. Here’s a start: public void withdraw(double amt) { } 24

  25. SavAcct Class (cont’d) Exercise: Write the addInt() method. Here’s a start: public void addInt() { } 25

  26. SavAcct Class (cont’d) public class SavAcct extends BankAcct { private double intRate; private double lowBal; // Constructor public SavAcct(String acct, double bal, double rate) { super(acct, bal); intRate = rate; lowBal = bal; } // overrides withdraw() public void withdraw(double amt) { super.withdraw(amt); if (getBalance() < lowBal) { lowBal = getBalance(); } } 26

  27. SavAcct Class (cont’d) // new method public void addInt() { deposit(lowBal*intRate); lowBal = getBalance(); } // other methods and instance fields are inherited } 27

  28. MMAcct Class We leave the remaining class, MMAcct,to the hands-on exercise. 28

  29. End of Lecture

More Related