Generic Classes Use Cases Inheritance Generic Classes The

Generic Classes Use Cases Inheritance

Generic Classes

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

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

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)

A Student. Collection Initialize Add • Head … Remove Is. Empty Remove. Helper

class Student. Collection public procedure Add(to. Add isoftype in Student) // contract comments here procedure Remove (to. Remove isoftype in Student) // contract comments here function Is. Empty returnsa Boolean // contract comments here procedure Initialize // contract comments here protected List. Node definesa record data isoftype Student next isoftype ptr toa List. Node endrecord // List. Node Head isoftype ptr toa List. Node

// Still in the protected section procedure Add(to. Add isoftype in Student) temp isoftype ptr toa List. Node temp <- new(List. Node) temp^. data <- to. Add temp^. next <- Head <- temp endprocedure // Add function Is. Empty returnsa Boolean Is. Empty returns (Head = NIL) endfunction // Is. Empty procedure Initialize Head <- NIL endprocedure // Initialize

// Still in the protected section procedure Remove (to. Remove isoftype in Student) Remove. Helper (Head, to. Remove) endprocedure // Remove procedure Remove. Helper (current iot in/out ptr toa List. Node, to. Remove isoftype in Student) if (current <> NIL) then if (current^. data = to. Remove) then current <- current^. next else Remove. Helper(current^. next, to. Remove) endif endprocedure // Remove. Helper endclass // Student. Collection

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

class Student. Collection public procedure Add(to. Add isoftype in Student) // contract comments here procedure Remove (to. Remove isoftype in Student) // contract comments here function Is. Empty returnsa Boolean // contract comments here procedure Initialize // contract comments here protected List. Node definesa record data isoftype Student next isoftype ptr toa List. Node endrecord // List. Node Head isoftype ptr toa List. Node

// Still in the protected section procedure Add(to. Add isoftype in Student) temp isoftype ptr toa List. Node temp <- new(List. Node) temp^. data <- to. Add temp^. next <- Head <- temp endprocedure // Add function Is. Empty returnsa Boolean Is. Empty returns (Head = NIL) endfunction // Is. Empty procedure Initialize Head <- NIL endprocedure // Initialize

// Still in the protected section procedure Remove (to. Remove isoftype in Student) Remove. Helper (Head, to. Remove) endprocedure // Remove procedure Remove. Helper (current iot in/out ptr toa List. Node, to. Remove isoftype in Student) if (current <> NIL) then if (current^. data = to. Remove) then current <- current^. next else Remove. Helper(current^. next, to. Remove) endif endprocedure // Remove. Helper endclass // Student. Collection

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?

A Collection Initialize Add • Head … Remove Is. Empty Remove. Helper

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.

class Collection (Data. Type) public procedure Add(to. Add isoftype in Data. Type) // contract comments here procedure Remove (to. Remove iot in Data. Type) // contract comments here function Is. Empty returnsa Boolean // contract comments here procedure Initialize // contract comments here protected List. Node definesa record data isoftype Data. Type next isoftype ptr toa List. Node endrecord // List. Node Head isoftype ptr toa List. Node

// Still in the protected section procedure Add(to. Add isoftype in Data. Type) temp isoftype ptr toa List. Node temp <- new(List. Node) temp^. data <- to. Add temp^. next <- Head <- temp endprocedure // Add function Is. Empty returnsa Boolean Is. Empty returns (Head = NIL) endfunction // Is. Empty procedure Initialize Head <- NIL endprocedure // Initialize

// Still in the protected section procedure Remove (to. Remove iot in Data. Type) Remove. Helper (Head, to. Remove) endprocedure // Remove procedure Remove. Helper (current iot in/out ptr toa List. Node, to. Remove iot in Data. Type) if (current <> NIL) then if (current^. data = to. Remove) then current <- current^. next else Remove. Helper(current^. next, to. Remove) endif endprocedure // Remove. Helper endclass // Collection

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

Using Objects of Generic Classes Just as before: algorithm Collection. Example. . . Numbers. Add(42) Numbers. Add(31) Numbers. Remove(42) if (Numbers. Is. Empty) then print(“Empty collection of numbers”) endif Word. List. Add(“CS is fun!”). . .

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.

Questions?

Use Cases

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.

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

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

Use Case Example A passenger wishing to go to another floor of the building presses the elevator call button. When an elevator is available, the doors open and the passenger enters the cage. The passenger presses one of the inside buttons to select the destination floor. The doors close and the elevator moves to the destination floor; the doors open and the passenger leaves. When an elevator requires maintenance, the maintainer disables the elevator call buttons, attaches his external control box and exercises individual elevator control commands and display features.

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

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

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

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)

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)

Questions?

Inheritance

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

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

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

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

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

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. Superclass Subclass Thing Elevator Door

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

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.

Inheriting from a Super. Class class <SUBCLASS_NAME> inherits <SUPERCLASS_NAME> public <CHANGES> protected <CHANGES> endclass // <SUBCLASS_NAME>

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

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

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

The Base Class Bank_Account Deposit Withdraw Initialize Get_Balance • balance

A Superclass 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

A Base Class (cont’d) //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

Inheritance by Extension • Imagine that we wish to create a new kind of Bank Account that is: – Identical to the base class in all respects, except one – We want to add the ability for the account to earn interest • Without inheritance, we’d have to write it from scratch, duplicating code, etc. • With inheritance, we need code only the new capability and inherit the rest.

Illustration of Inheritance Bank_Account Deposit Withdraw • balance Initialize Get_Balance Savings_Account • RATE • MIN_BALANCE Calc_Interest // protected section Function Calc_Interest. . . endfunction

Inheritance by Extension class Savings_Account inherits Bank_Account public // inherits Deposit, Withdraw, Get_Balance function Calc_Interest returnsa Num // comments here protected // inherits balance RATE is. 023 // 2. 3% MIN_BALANCE is 500

Inheritance by Extension (cont’d) // still in protected section function Calc_Interest returnsa Num if (balance >= MIN_BALANCE) then Calc_Interest returns balance * RATE else Calc_Interest returns 0 endif endfunction // Calc_Interest endclass // Savings_Account

Using Subclasses in Algorithms algorithm Bank. Example uses Savings_Account my_savings isoftype Savings_Account my_savings. Initialize // superclass method. . . my_savings. Deposit(500) // superclass method my_interest isoftype Num my_interest <- my_savings. Calc_Interest // subclass method. . . my_savings. Withdraw(amount) // superclass method endalgorithm // Bank. Example

Inheritance by Redefinition • Imagine that we wish to create a new kind of Savings Account that is: – identical to Savings Account in all respects, except one: • we want to change the way in which withdrawals are handled • the base class already handles withdrawals, but now we want a subclass that does them differently. • Without inheritance, we’d have to rewrite it from scratch. • With inheritance, we need code only the new way that we want withdrawals to work,

Illustration of Redefinition Savings_Account • RATE • MIN_BALANCE Calc_Interest Cool_Savings Allow_Overdraft • overdraft_ok • OVERDRAFT_CHARGE // protected section procedure Withdraw. . . procedure Initialize. . .

Inheritance by Redefinition class Cool_Savings inherits Savings_Account public procedure Allow_Overdraft(ok iot in Boolean) // new method: extending superclass protected overdraft_ok isoftype Boolean // extension OVERDRAFT_CHARGE is 20 // extension procedure Allow_Overdraft(ok iot in Boolean) overdraft_ok <- ok endprocedure // Allow_Overdraft

Inheritance and Redefinition (cont’d) // still in protected section procedure Withdraw(amt isoftype in/out Num) if (overdraft_ok) then balance <- balance - amt if (balance < 0) then balance <- balance – OVERDRAFT_CHARGE endif else Super. Withdraw(amt) // calls super version endif endprocedure // Withdraw procedure Initialize // redefines Init. Super. Initialize // uses super method overdraft_ok <- FALSE // and adds to it. endprocedure // Initialize endclass // Cool_Savings

Super • “Super” is a built-in attribute to all classes which inherit from another class. • “Super” allows us to access the implementation of a method in the superclass. • For example, Super. Initialize executes the Initialize implementation in the superclass of the class.

Using Subclasses in Algorithms my_cool_savings isoftype Cool_Savings my_cool_savings. Initialize // both my_cool_savings. Deposit(250) // super method. . . my_cool_savings. Withdraw(amount) // both // check amount to see if correctly done my_cool_savings. Allow_Overdraft(TRUE) // subclass method my_interest isoftype Num my_interest <- my_cool_savings. Calc_Interest // super method. . . my_cool_savings. Withdraw(amount)// subclass method

Summary of Inheritance • Extension take a base class and add new capabilities to it (methods, attributes). • Redefinition take a base class and redefine an existing method, implement it in a new way in order to change capability or performance. • Both allow us to code only the differences.

Questions?