Generic Classes Use Cases Inheritance

1. Lecture 20 Generic ClassesUse CasesInheritance

2. Generic Classes

3. The Scenario • Imagine that you’ve just finished writing a wonderful NumberQueue class that works perfectly. • But what about a Queue to hold strings? … or Booleans? … or user-defined records?

4. A Proper Balance Notice that in the process of creating the NumberQueue class… • We’ve given too much informationto the class (supplier). • The algorithm (client) should specifywhat to hold. • The Queue shouldn’t care about what it holds. • The Queue should simply hold the items!

5. Achieving Proper Balance • Hide details from the client • Using protected section of the class • Keep certain information in the client • The object doesn’t / shouldn’t know about certain details • Better abstraction and makes the class generic (more reusable)

6. A StudentCollection StudentCollection Initialize • Head Add … Remove RemoveHelper IsEmpty

7. class StudentCollection public procedure Add(toAdd isoftype in Student) // contract comments here procedure Remove (toRemove isoftype in Student) // contract comments here function IsEmpty returnsa Boolean // contract comments here procedure Initialize // contract comments here protected ListNode definesa record data isoftype Student next isoftype ptr toa ListNode endrecord // ListNode Head isoftype ptr toa ListNode

8. // Still in the protected section procedure Add(toAdd isoftype in Student) temp isoftype ptr toa ListNode temp <- new(ListNode) temp^.data <- toAdd temp^.next <- Head Head <- temp endprocedure // Add function IsEmpty returnsa Boolean IsEmpty returns (Head = NIL) endfunction // IsEmpty procedure Initialize Head <- NIL endprocedure // Initialize

9. // Still in the protected section procedure Remove (toRemove isoftype in Student) RemoveHelper (Head, toRemove) endprocedure // Remove procedure RemoveHelper (current iot in/out ptr toa ListNode, toRemove isoftype in Student) if (current <> NIL) then if (current^.data = toRemove) then current <- current^.next else RemoveHelper(current^.next, toRemove) endif endif endprocedure // RemoveHelper endclass // StudentCollection

10. Other Collections • What about other collections? • String • Num • Etc. • Maintaining multiple classes would be counterproductive.

11. class StudentCollection public procedure Add(toAdd isoftype in Student) // contract comments here procedure Remove (toRemove isoftype in Student) // contract comments here function IsEmpty returnsa Boolean // contract comments here procedure Initialize // contract comments here protected ListNode definesa record data isoftype Student next isoftype ptr toa ListNode endrecord // ListNode Head isoftype ptr toa ListNode

12. // Still in the protected section procedure Add(toAdd isoftype in Student) temp isoftype ptr toa ListNode temp <- new(ListNode) temp^.data <- toAdd temp^.next <- Head Head <- temp endprocedure // Add function IsEmpty returnsa Boolean IsEmpty returns (Head = NIL) endfunction // IsEmpty procedure Initialize Head <- NIL endprocedure // Initialize

13. // Still in the protected section procedure Remove (toRemove isoftype in Student) RemoveHelper (Head, toRemove) endprocedure // Remove procedure RemoveHelper (current iot in/out ptr toa ListNode, toRemove isoftype in Student) if (current <> NIL) then if (current^.data = toRemove) then current <- current^.next else RemoveHelper(current^.next, toRemove) endif endif endprocedure // RemoveHelper endclass // StudentCollection

14. Better Abstraction • Why not let the class worry only about managing the items? • It should have no concept of what it’s holding. • This will dramatically increase reusability. • Why not specify the type of items to hold via a parameter?

15. A Collection Collection Initialize • Head Add … Remove RemoveHelper IsEmpty

16. Making the Class Generic • Instead of a specific data type to hold, declare a “magic word” on which we’ll later search and replace. • When the class is instantiated later into an object, then specify the desired type. • Use a parameter to the class definition and instantiation.

17. class Collection (DataType) public procedure Add(toAdd isoftype in DataType) // contract comments here procedure Remove (toRemove iot in DataType) // contract comments here function IsEmpty returnsa Boolean // contract comments here procedure Initialize // contract comments here protected ListNode definesa record data isoftype DataType next isoftype ptr toa ListNode endrecord // ListNode Head isoftype ptr toa ListNode

18. // Still in the protected section procedure Add(toAdd isoftype in DataType) temp isoftype ptr toa ListNode temp <- new(ListNode) temp^.data <- toAdd temp^.next <- Head Head <- temp endprocedure // Add function IsEmpty returnsa Boolean IsEmpty returns (Head = NIL) endfunction // IsEmpty procedure Initialize Head <- NIL endprocedure // Initialize

19. // Still in the protected section procedure Remove (toRemove iot in DataType) RemoveHelper (Head, toRemove) endprocedure // Remove procedure RemoveHelper (current iot in/out ptr toa ListNode, toRemove iot in DataType) if (current <> NIL) then if (current^.data = toRemove) then current <- current^.next else RemoveHelper(current^.next, toRemove) endif endif endprocedure // RemoveHelper endclass // Collection

20. Instantiating Generic Classes • Simply add a type as a parameter to the declaration of the object: Algorithm CollectionExample uses Collection Students isoftype Collection(Student) WordList isoftype Collection(String) Numbers isoftype Collection(Num)

21. Using Objects of Generic Classes Just as before: algorithm CollectionExample ... Numbers.Add(42) Numbers.Add(31) Numbers.Remove(42) if (Numbers.IsEmpty) then print(“Empty collection of numbers”) endif WordList.Add(“CS is fun!”) ...

22. Summary • Everything in its proper place • Hide details from the client in the protected section • Hide details from the class using generic parameters • This gives better abstraction and increases reusability.

23. Questions?

24. Use Cases

25. Designing an OO Solution • Ask yourself, “What are the characteristics of the system I want to model?” • Use natural language to describe scenarios, or cases of use. • Natural language descriptions define how each user of a system intends to use it.

26. Use Cases • Frequently causes you to think more clearly about the system design “before it’s too late.” • Useful in providing introduction to the system requirements: • Identify users • Identify major system components (classes) • Identify methods and attributes needed for each component

27. Use Case Design • From the use case scenarios, we can construct our classes with methods and attributes: • Nouns become classes or attributes • Verbs become methods

28. Use Case Example A passenger wishing to go to another floor of the building presses the elevatorcall button. When an elevator is available, the doorsopen and the passengerenters the cage. The passengerpresses one of the inside buttons to select the destination floor. The doorsclose and the elevatormoves to the destination floor; the doorsopen and the passengerleaves. When an elevatorrequires maintenance, the maintainerdisables the elevatorcall buttons, attaches his external control box and exercises individual elevator control commands and displayfeatures.

29. Passenger Elevator #1 Passenger Elevator #2 Doors Doors Lobby Doors Doors Passenger Elevator #3 Service Elevator Doors Visual Diagram of A System

30. Relationships between Classes: “Has-a” • Identity • Weight • Doors • People • Position Elevator Open Doors Close Doors Move to Floor • Identity • Weight • Color • Position Door Open Close

31. Thing Move Elevator Door Open Open Doors Close Close Doors Relationships between Classes: “Is-A”

32. Issues • What are the main tasks to be performed by each actor? (Class definition) • What could go wrong with each task? (Fault tolerance and recovery) • What information is required for each task, produced by it, or changed by it? (Information and method passing)

33. Issues • Do the actors have to be involved by providing input about the external world? (Interface) • What information does the actor desire from the system? (User-centered design) • Should the actor be informed of unexpected events or unavailable equipment or capabilities? (Visibility)

34. Questions?

35. Inheritance

36. Relationships Between Classes • Has-A • One class can provide services to another, acting as an attribute • Is-A • One class inherits the abilities of another class

37. Elevator Instances Passenger Elevator #1 Passenger Elevator #2 Doors Doors Lobby Doors Doors Passenger Elevator #3 Service Elevator Doors

38. Relationships between Classes:Using - “Has-A” • Identity • Color • State • Doors • Position Elevator Open Doors Close Doors Move to Floor • Identity • State • Color • IsOpen Door “Has-A” Open Close

39. Relationships between Classes:Being - “Is-A” • Identity • Color • State Thing Move “Is-A” Door Elevator • Position • Doors • IsOpen Open Open Doors Close Close Doors

40. Defining the Differences • Classes often share capabilities • We want to avoid re-coding these capabilities • Re-use of these would be best to • Improves maintainability • Reduces cost • Improves “real world” modeling

41. Inheritance Defined • When one class re-uses the capabilities defined in another class. • The new subclass gains all the methods and attributes of the superclass. Thing Superclass Elevator Door Subclass

42. Inheritance Example Thing • Identity • Color • State Move Door Elevator • Position • Doors • IsOpen Open Open Doors Close Close Doors

43. Benefits of Inheritance • Saves effort of “reinventing the wheel” • Allows us to build on existing code, specializing without having to copy it, rewrite it, etc. • To create the subclass, we need to program only the differences between the superclass and the subclass that inherits from it. • Allows for flexibility in class definitions.

44. Inheriting from a SuperClass class <SUBCLASS_NAME> inherits <SUPERCLASS_NAME> public <CHANGES> protected <CHANGES> endclass // <SUBCLASS_NAME>

45. Two Types of Inheritance • Extension • Adds attributes and methods • Redefinition • Changes/modifies existing methods, specializing as needed

46. Inheritance Examples Given a bank account class… • Extension • Add the capability of calculating interest • Redefinition • Redefine how withdraws occur

47. Consider a primitive bank account which allows only three kinds of transactions: Deposits Withdrawals Ability to check current balance Inheritance Example: Bank Accounts

48. The Base Class Bank_Account Bank_Account Deposit • balance Withdraw Initialize Get_Balance

49. A Superclass Bank_Account • class Bank_Account • public • procedure Deposit (amt isoftype in Num) • // comments here • procedure Withdraw(amt isoftype in/out Num) • // only allows withdraw up to current balance • function Get_Balance returnsa Num • // comments here • procedure Initialize • // comments here • protected • balance isoftype Num • procedure Deposit (amt isoftype in Num) • balance <- balance + amt • endprocedure // Deposit

50. //still in protected section procedure Withdraw(amt isoftype in/out Num) if (balance < amt) then amt <- balance endif balance <- balance - amt endprocedure // Withdraw function Get_Balance returnsa Num Get_Balance returns balance endfunction // Get_Balance procedure Initialize balance <- 0 endprocedure // Initialize endclass // Bank_Account A Base Class (cont’d)