C++: Object Oriented
Jim Allert
Instructor: Jim Allert
Email: jallert@d.umn.edu
Office: Heller Hall 324A
Hours: 10:00-12:00 MWF
Registration and Waiting
Waiting list priorities set by CSE
See me after class if you are interested in
a override
Course goals and prerequisites
Syllabus and logistics
C++: Larger picture and motivation
C++: the kernel language
Course Goals
Change the way you think
OOP different from traditional procedural
Learning the C++ constructs
why and when use a construct
when not to use a construct
C++ syntax
the easiest
You Will Not...
Become an expert C++ programmer
A starting point for further study
Learn all the features of C++
C++ is a very complex language
Learn advanced OOP techniques
Become expert at object-oriented design
Read a book on Software Engineering
Expected Background
C programming skills
Control structures
Pointers (linked lists)
No object-oriented experience necessary
Experience with:
Turbo C/C++
development environment
Textbooks and on-line resources
please read assigned chapter(s) before
Assignments and Exams
Group work not allowed.
UMD computer accounts and facilities
Email is the preferred medium
Problems with homework assignments,
1. Contact TA
2. Contact me
Problems with TA or TA explanations
Contact me
Outline: the Big Picture
History of programming languages
Approaches to Program Design
Overview of object-oriented programming
Object-oriented programming and C++
History of Programming
 pre-mid-1950’s
machine and assembly language
“ad hoc” data representation and control
 1960’s
Fortran, Cobol, Algol
arrays, control structures
Simula 67, forerunner of C++
 1970’s
C, Pascal
block program structure, structured control
stepwise refinement
History of Programming
 Early 80’s
Modula-2, Ada
modules, Abstract Data Types (ADT’s)
 1980’s: “Classic” OOP
C++, Smalltalk
inheritance, polymorphism
 1990’s:
C++, Java
templates, iterators, exceptions, interfaces
Approaches to Program Design
 Stepwise refinement
Based on the operations performed
General operations iteratively decomposed into
specific ones
 Object-oriented design
Problem decomposed into real-world objects
Objects have a well-defined interface
Focus on behavior and collaboration of objects
Structure Chart Boxes
Example: getting from UMD to
Subtask 1: Get in car at parking lot …
Subtask 2: Drive to Minneapolis
Subtask 3: Find MetroDome
Subtask 4: Get out of car
Developing an Algorithm
Strategy (cont): repetitively divide tasks
until each task is easily solved
Example: Subtask 2 - Drive to Minneapolis
2.1 Drive east to I35
2.2 Drive south to I35W
2.3 Drive south to Minneapolis
Each division of a task is a “stepwise
Stepwise Refinement
Do stepwise refinement until all tasks
Example: 2.1 - Drive east to I35
Exit parking lot to East
Turn right on Woodland
Turn left on 21st
Enter I35
This process is know as Top-Down Design
Multi-layer Structure Chart
U M D to
M e tro D o m e
G e t in C a r
D rive to
M in n e a p o lis
F in d
M e tro D o m e
D rive e a st
to I3 5
D rive so u th
to I3 5 W
S o u th to
M in n e a p o lis
E xit P a rkin g
Lo t
R ig h t a t
W o o d la n d
L e ft o n 2 1 st
G e t o ut of
C ar
E n te r I3 5
Another Example
Problem: Balance checkbook
Top-level tasks
1. Get information
2. Perform computations
3. Print results
Bala nce
C heckbo ok
Inform a tio n
C om p utation s
Prin t
R esults
Pseudo-code Example
1. Get information
1.1 Get starting balance
1.2 Get transaction type
1.3 Get transaction amount
2. Perform computations
2.1 IF deposit THEN add to balance ELSE subtract
from balance
3. Print results
3.1 Print starting balance
3.2. Print transaction
3.2.1 Print transaction type
3.2.2 Print transaction amount
3.3 Print ending balance
Motivation for OO approach
More transparent mapping between:
requirements, design, and implementation
easier verification and validation
Lower software maintenance costs
danger of “ripple effect” reduced
Better code reuse
reuse by “tweaking” can be avoided
Bank account object design
Bank Account
Data portion
OOP broad overview
1. Define bank account object
a. Data members
b. Member functions
2. Program
a. Instantiate a bank account object
b. Use bank account object
Bank_account my_checking;
cout << my_checking.get_balance();
cout << my_checking.get_balance();
Manufacturers, Clients, Users
Manufacturers build objects
Clients use objects in programs
client code uses objects you make available
through your class definitions.
Users use programs
We are interested in object
manufacturers and clients here
OOProgramming: Concepts
Objects and Classes
Dynamic binding
essential qualities from incidental ones
Behavior is essential
Implementation is incidental
Example: an interface to a vending machine
as its abstraction
essential behavior: dispensing products
incidental implementation: the actual products
Explicit boundary between abstraction and
Encapsulation of all essential characteristics
of the object
Frees developers to change implementation
list processing using arrays
list processing using linked lists
Protects clients from using unstable code
Objects and Classes
identifiable component in problem domain
Abstract Data Type (ADT): state + operations
House: an Object
data state:
kitchen_lights, data: on/off
room_temperature, data: degrees
House blueprint: a Class
Object SingleFamilyHouse is a
kind of object House
Inherits all state and services
Adds new ones
Reuse and extend code
Objects of related types can be used
Can always use a specialized object where a
generic one is allowed
Example: appraising a house
generic appraisal form applied to specific homes
Dynamic Binding
Dynamic binding
Object methods selected at run time
Or: interface matched with implementation
at run-time
OOP Concepts Recap
Objects and Classes
Dynamic binding
Object-based programming
Object-oriented programming
(C++, Java)
Motivation: why C++ for OOP?
Large user community
high-quality compilers and development tools
for many platforms
learning aids: books, conferences,
newsgroup, seminars, consultants
Multi-paradigm language
Procedural: better C, Object-based
Legacy code: (mostly) backward
compatible with C
C++ Language Evolution
Simula (Norway, late 60-s)
Bjarne Stroustrup, Bell Labs, early 80’s
Complex simulation software
“C with classes”
features and complexity increased with time
we are lucky - ANSI standard created
and vendors are supporting it
C++ Distinguishing
Strong static type checking
“Manual” memory management
no automatic garbage collection
Supports multiple programming models
procedural and object-oriented
Multiple inheritance
Operator overloading

No Slide Title