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 A class can contain an object of another class class Dateclass Employee {public:{public: // methods//methodsprivate:// data }; char lastName[25]; char firstName[25]; Date birthdate; Date hiredate; }; Composition (example not in textbook)

4 Date class

5 // DATE1.H #ifndefDATE1_H #defineDATE1_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 int checkDay(int); }; #endif

6 Date::Date(int mn, int dy, 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(int testDay) { static int daysPerMonth[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 using namespace std; #include #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 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; } For the Birthdate object For the Hiredate object Parameters to the Employee constructor

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

1-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

1-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

1-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

1-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

1-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

1-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?

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

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

1-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

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

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

1-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

1-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

1-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

1-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

1-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