1 / 39

Object Oriented Design

Object Oriented Design. CSC 171 FALL 2001 LECTURE 12. 1944 - The first large scale, automatic, general purpose, electromechanical calculator (aka IBM Automatic Sequence Control Calculator [ASCC])

editht
Télécharger la présentation

Object Oriented Design

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. Object Oriented Design CSC 171 FALL 2001 LECTURE 12

  2. 1944 - The first large scale, automatic, general purpose, electromechanical calculator (aka IBM Automatic Sequence Control Calculator [ASCC]) Intended to compute navigation tables -- the same purpose as intended by Babbage for the Difference Engine History: Harvard Mark I

  3. 1945 - Grace Murray Hopper, working in a temporary World War I building at Harvard University on the Mark II computer, found the first computer bug beaten to death in the jaws of a relay. History: The first bug

  4. Design Methodology • Problem Definition • Requirements Analysis • Architecture • Construction • Testing • Future Improvements

  5. CRC cards Classes, Responsibilities, Collaborators

  6. Hierarchies • Humans have found that organizing concepts into hierarchies a useful method of organizing information

  7. Inheritance Hierarchies • Object oriented languages, such as JAVA allows us to group classes into inheritance hierarchies. • The most general classes are near the root • The more specific classes are near the leaves

  8. Example: Banking Systems • Consider a system that supports Savings and Checking accounts • What are the similarities? • What are the specifics

  9. Accounts • Both savings and Checking accounts support the idea of • Balance • Deposit • Withdraw • Savings accounts pay interest checking accounts do not • Checking accounts have transaction fees, savings accounts do not

  10. Super & Sub classes • More general concepts are in super classes • More specific concepts are in sub classes • Sub classes extend (inherit from) superclasses • When we find, though CRC analysis, that two classes share many responsibilities, we think about making a super-class

  11. Why inheritance? • The power of inheritance is that sub-classes inherit the capabilities of the super-classes they extend • This reduces code redundancy

  12. Example: Banking systems • Bank accounts are a type of object • Savings accounts are a type of bank account • Checking Accounts are bank accounts public class BankAccount { . . . } public class SavingsAccount extends BankAccount { . . .} public class CheckingAccount extends BankAccount { . . .}

  13. Bank Accounts public class BankAccount { private double balance; public double getBalance() { . . . } public void deposit(double d) { . . .} public void withdraw(double d){ . . . } }

  14. Savings account • Savings accounts are like Bank accounts but they support the notion of interest

  15. Savings Accounts

  16. public class SavingsAccount extends BankAccount { private double interestRate; public void addInterest() { double interest = getBalance() * interestRate/100; balance += interest; // will this work? } public SavingsAccount(double rate){ interestRate = rate; } }

  17. Savings Accounts public class SavingsAccount extends BankAccount { private double interestRate; public void addInterest() { double interest = getBalance() * interestRate/100; deposit(interest); // where is this defined? } public SavingsAccount(double rate){ interestRate = rate; } }

  18. Checking accounts • For checking accounts, we need to keep track of transactions • So, we need to add the ability to deduct fees • However, we also need to change deposit

  19. Checking Accounts public class CheckingAccount extends BankAccount { private int transactionCount; // how about this? public void deposit (double amount){ transactionCount++; deposit(amount); } ….

  20. Checking Accounts public class CheckingAccount extends BankAccount { private int transactionCount; // this works better public void deposit (double amount){ transactionCount++; super.deposit(amount); } ….

  21. Checking Accounts // and of course public void withdraw (double amount){ transactionCount++; super.withdraw(amount); } ….

  22. Checking Accounts // and, in addition public void deductFees (){ if (transactionCount > FREE_TRANS) { double fees = TRANS_FEE * (transactionCount – FREE_TRANS); super.withdraw(fees); } transactionCount = 0 ; } private static final int FREE_TRANS = 3; private static final double TRANS_FEE = 2.0 ; }

  23. Polymorphism • Inheritance is thought of as an “is-a” relationship • A CheckingAccount “is-a” BankAccount • A BankAccount is not a CheckingAccount • Due to this fact, it is possible to use a subclass object in place of a superclass object

  24. Polymorphism Example • Consider the problem of “transfer” • We want to be able to transfer • Savings -> savings • Savings -> checking • Checking -> savings • Checking -> checking • In short, we want to transfer from one BankAccount, to another

  25. Transfer • A method of BankAccount public void transfer(BankAccount other, double amount) { withdraw(amount); other.deposit(amount); }

  26. Set up some accounts CheckingAccount harrysChecking = new CheckingAccount(); harrysChecking.deposit(1000); SavingsAccount harrysSavings = new SavingsAccount(); harrysSavings.deposit(5000);

  27. Using Transfer harrysSavings.transfer(harrysChecking,500); Does this work? • transfer is defined on BankAccounts • transfer takes a BankAccount as a parameter

  28. Polymorphism & Arrays BankAccount myBank = new BankAccount[accnts]; myBank[0]= new CheckingAccount(); myBank[0].deposit(1000); myBank[1]= new SavingsAccount(); myBank[1].deposit(1000);

  29. instanceOf for (int i = 0 ; i<myBank.length;i++){ if (myBank[i] instanceOf CheckingAccount) myBank[i].deductFees(); if (myBank[i] instanceOf SavingsAccount) myBank[i].addInterest(); }

  30. Interfaces • Suppose we wanted to be able to sort Savings accounts based on interest rate • We could write our own sort method, but there are lots of good sorts in the JAVA lib • If objects are of the Comparable type, many methods in the JAVA lib could sort them

  31. One Approach public class SavingsAccount extends BankAccount, Comparable { . . . .} • This does not work • Multiple inheritance ins not support in JAVA

  32. Instead – use an interface public interface Comparable { int compareTo(Object other); // no impementation } public class SavingsAccount extends BankAccount implements Comparable { public int compareTo(Object other) { // we supply implementation } . . . . }

  33. Implement an interface public int compareTo(Object other) { // sub is super, not super sub – So, make it so SavingsAccount otherAccount = (SavingsAccount) other; if (interestRate < otherAccount.interestRate) return 1; if (interestRate > otherAccount.interestRate) return -1; }

  34. Other interfaces • Listeners of most kinds

More Related