Object-Oriented Programming Using C++

1. Object-Oriented Programming Using C++ CLASS 5

2. Object Composition • Object composition occurs when a class contains an instance of another class. • Creates a “has a” relationship between classes.

3. Composition (example not in textbook) A class can contain an object of another class class Date class Employee { public: { public: // methods //methods private: private: // data // data }; char lastName[25]; char firstName[25]; Date birthdate; Date hiredate; };

4. Date class

5. // DATE1.H #ifndef DATE1_H #define DATE1_H class Date { public: Date(int = 1, int = 1, int = 1900); // default constructor void print ( ) const; ~Date( ); private: int month; // 1-12 int day; // 1-31 based on month int year; // any year intcheckDay(int); }; #endif

6. Date::Date(intmn, intdy, int yr) { if (mn > 0 && mn <= 12) month = mn; else { month = 1; cout << “Month 1” << mn << “ invalid.Set to month 1.” << endl; } year = yr; // could also check day = checkDay(dy); // validate the day cout << “Date object constructor for date ”; print( ); cout << endl; }

7. int Date::checkDay(inttestDay) { static intdaysPerMonth[13] = {0, 31, 28, 31, 30 31, 30, 31, 31, 30, 31, 30, 31}; if (testDay > 0 && testDay <= daysPerMonth[month]) return testDay; if (month == 2 && testDay == 29 && (year % 400 == 0 || (year % 4 == 0 && year % 100 !=0))) return testDay; cout<<“Day”<< testDay << “ invalid. Set to day 1.”<<endl; return 1; }

8. // Print Date object in form month/day/year void Date::print( ) const { cout << month << ‘/’ << day << ‘/’ << year; } Date::~Date( ) { cout << “Date object destructor for date ”; print( ); cout << endl; }

9. Employee class

10. // emply1.h#ifndef EMPLY1_H#define EMPLY1_H#include "date1.h“class Employee {public: Employee( char *, char *, int, int, int, int, int, int ); void print() const; ~Employee(); private: char firstName[ 25 ]; char lastName[ 25 ]; const Date birthDate; const Date hireDate;};#endif

11. // Member function definitions for Employee class. #include <iostream> using namespace std; #include <cstring> #include "emply1.h" #include "date1.h"

12. Employee::Employee( char *fname, char *lname, int bmonth, int bday, int byear, int hmonth, int hday, int hyear ) : birthDate( bmonth, bday, byear ), hireDate( hmonth, hday, hyear ) { // body of constructor

13. Employee::Employee( char *fname, char *lname, int bmonth, int bday, int byear, int hmonth, int hday, int hyear ) : birthDate( bmonth, bday, byear ), hireDate( hmonth, hday, hyear ) // constructor of date class called twice: // once for the birthDate object // once for the hireDate object { // body of constructor

14. int length = strlen( fname ); length = ( length < 25 ? length : 24 ); strncpy( firstName, fname, length ); firstName[ length ] = '\0'; length = strlen( lname ); length = ( length < 25 ? length : 24 ); strncpy( lastName, lname, length ); lastName[ length ] = '\0'; cout << "Employee object constructor: “ << firstName << ' ' << lastName << endl; }

15. void Employee::print() const { cout << lastName << ", " << firstName << "\nHired: "; hireDate.print(); cout << " Birth date: "; birthDate.print(); cout << endl; } Employee::~Employee() { cout << "Employee object destructor: " << lastName << ", " << firstName << endl;} P. 466

16. #include <iostream>using namespace std;#include "emply1.h“int main() {Employee e( "Bob", "Jones", 7, 24, 1949, 3, 12, 1988 ); e.print(); Date d( 14, 35, 1994 ); cout << endl; return 0; } Parameters to the Employee constructor For the Birthdate object For the Hiredate object

17. Abstract Data Types • Modularity • Keeps the complexity of a large program manageable by systematically controlling the interaction of its components • Isolates errors • Eliminates redundancies

18. Abstract Data Types • Modularity (Continued) • A modular program is • Easier to write • Easier to read • Easier to modify

19. Abstract Data Types • Functional abstraction • Separates the purpose and use of a module from its implementation • A module’s specifications should • Detail how the module behaves • Be independent of the module’s implementation

20. Abstract Data Types • Information hiding • Hides certain implementation details within a module • Makes these details inaccessible from outside the module

21. Abstract Data Types • Typical operations on data • Add data to a data collection • Remove data from a data collection • Ask questions about the data in a data collection

22. Abstract Data Types • Data abstraction • Asks you to think what you can do to a collection of data independently of how you do it • Allows you to develop each data structure in relative isolation from the rest of the solution • A natural extension of functional abstraction

23. Abstract Data Types • Abstract data type (ADT) • An ADT is composed of • A collection of data • A set of operations on that data • Specifications of an ADT indicate • What the ADT operations do, not how to implement them • Implementation of an ADT • Includes choosing a particular data structure

24. Abstract Data Types Figure 3-4 A wall of ADT operations isolates a data structure from the program that uses it

25. Object-Oriented Analysis and Design • Object-oriented design (OOD) • Expresses an understanding of a solution that fulfills the requirements discovered during OOA • Describes a solution in terms of • Software objects • The collaborations of these objects with one another • Objects collaborate when they send messages (call each other’s operations) • Collaborations should be meaningful and minimal • Creates one or more models of a solution • Some emphasize interactions among objects • Others emphasize relationships among objects

26. Applying the UML to OOA/D • Unified Modeling Language (UML) • A tool for exploration and communication during the design of a solution • Models a problem domain in terms of objects independently of a programming language • Visually represents object-oriented solutions as diagrams • Its visual nature is an advantage, since we are visual creatures • Enables members of a programming team to communicate visually with one another and gain a common understanding of the system being built

27. Applying the UML to OOA/D • UML use case for OOA • A set of textual scenarios (stories) of the solution • Each scenario describes the system’s behavior under certain circumstances from the perspective of the user • Focus on the responsibilities of the system to meeting a user’s goals • Main success scenario (happy path): interaction between user and system when all goes well • Alternate scenarios: interaction between user and system under exceptional circumstances • Find noteworthy objects, attributes, and associations within the scenarios

28. Applying the UML to OOA/D • An example of a main success scenario • Customer asks to withdraw money from a bank account • Bank identifies and authenticates customer • Bank gets account type, account number, and withdrawal amount from customer • Bank verifies that account balance is greater than withdrawal amount • Bank generates receipt for the transaction • Bank counts out the correct amount of money for customer • Customer leaves bank

29. Applying the UML to OOA/D • An example of an alternate scenario • Customer asks to withdraw money from a bank account • Bank identifies, but fails to authenticate customer • Bank refuses to process the customer’s request • Customer leaves bank

30. Applying the UML to OOA/D • UML sequence (interaction) diagram for OOD • Models the scenarios in a use case • Shows the interactions among objects over time • Lets you visualize the messages sent among objects in a scenario and their order of occurrence • Helps to define the responsibilities of the objects • What must an object remember? • What must an object do for other objects?

31. Applying the UML to OOA/D Figure 1-2 Sequence diagram for the main success scenario

32. Applying the UML to OOA/D Figure 1-3 Sequence diagram showing the creation of a new object

33. Applying the UML to OOA/D • UML class (static) diagram • Represents a conceptual model of a class of objects in a language-independent way • Shows the name, attributes, and operations of a class • Shows how multiple classes are related to one another

34. Applying the UML to OOA/D Figure 1-4 Three possible class diagrams for a class of banks

35. Applying the UML to OOA/D Figure 1-5 A UML class diagram of a banking system

36. Applying the UML to OOA/D • Class relationships • Association • The classes know about each other • Example: The Bank and Customer classes • Aggregation (Containment) • One class contains an instance of another class • Example: The Bank and Account classes • The lifetime of the containing object and the object contained are not necessarily the same • Banks “live” longer than the accounts they contain

37. Applying the UML to OOA/D • Class relationships (Continued) • Composition • A stronger form of aggregation • The lifetime of the containing object and the object contained are the same • Example: A ballpoint pen • When the pen “dies,” so does the ball

38. Applying the UML to OOA/D • Class relationships (Continued) • Generalization • Indicates a family of classes related by inheritance • Example: Account is an ancestor class; the attributes and operations of Account are inherited by the descendant classes, Checking and Savings

39. Applying the UML to OOA/D • Notation • Association • A relationship between two classes is shown by a connecting solid line • Relationships more specific than association are indicated with arrowheads, as you will see • Multiplicities: Optional numbers at the end(s) of an association or other relationship • Each bank object is associated with zero or more customers (denoted 0..*), but each customer is associated with one bank • Each customer can have multiple accounts of any type, but an account can belong to only one customer

40. Applying the UML to OOA/D • Notation (Continued) • Aggregation (Containment) • Denoted by an open diamond arrowhead pointing to the containing class • Composition • Denoted by a filled-in diamond arrowhead pointing to the containing class • Generalization (Inheritance) • Denoted by an open triangular arrowhead pointing to the ancestor (general or parent) class • UML also provides notation to specify visibility, type, parameter, and default value information