Post on 03-Jan-2016
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 Date class Employee{ public: { public:
// methods //methodsprivate: private:// data // data
}; char lastName[25]; char firstName[25]; Date birthdate; Date hiredate;
};
Composition (example not in textbook)
4
Date class
5
// DATE1.H#ifndef DATE1_H#define DATE1_Hclass Date {public:
Date(int = 1, int = 1, int = 1900); // default constructor
void print ( ) const; ~Date( );
private:int month; // 1-12int day; // 1-31 based on monthint year; // any yearint 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 checkday = 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/yearvoid 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; }
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