CIS601: Object-Oriented
Programming in C++
Lesson #1
1
Note: CIS 601 notes were originally developed by H. Zhu for NJIT DL Program. The notes were subsequently revised by M. Deek.
Contact Information
Email: maura.a.deek@njit.edu
Web: www.ccs.njit.edu/maura
2
Goals for the Course
To
understand Object Oriented
programming
To further develop your C++ skills
3
Course Coverage
 Fundamentals
of object-oriented
programming
*Data abstraction
*Encapsulation
*Inheritance
*Dynamic binding
*Polymorphism
4
Course Coverage cont.
C++
will be used as a vehicle to
illustrate and implement OOP
concepts.
Object-oriented paradigm will be
applied to design and programming.
5
Course Coverage cont.
 Effects
of OO methodology on software
design
 maintenance
 extensibility
 reusability
6
Prerequisites
 Working
knowledge of
 C/C++
 Familiarity
with operating systems
 Familiarity with compilers
7
Lectures
 1.
Introduction to Object-Oriented
Programming
 2.
 3.
Overview of basic structures of C++
Objects and Classes
 4. Objects and Classes in C++
 5. Inheritance
 6. Inheritance in C++
 7. Polymorphism and That in C++
8
Lectures cont.
 8.
 9.
Operator Overloading in C++
Templates and Friends in C++
 10. I/O Streams in C++
 11. Exception Handling in C++
 12. Container Classes in C++
 13. Object-Oriented Analysis and Design
 14. Case Studies and Review
9
Thinking Methodology
Induction
From
specialization to generalization
create the word “dog” from different
dogs
to
Dog
10
Thinking Methodology
Deduction(infer)
From
generalization to specialization
the word “dog” you have learned
that an animal is or is not a dog.
From
DOG
11
Design Methodologies
 Functional
 The
decomposition (Top-Down)
whole system is characterized by a
single function, and then the function is
decomposed into a set of functions in a
process of stepwise refinement.
12
Functional decomposition
The System
Function1
Desk
13
Function2
Table top
Studying
Function3
... ...
Filing cabinet Bookshelves
... ...
... ...
Function11
Function12
Left drawer
Middle drawer Right drawer
Design Methodologies
 Functional
 To
composition (bottom-up)
create different components of a
function from a library of functions.
 To integrate components into a module
and form a more significant function.
14
Functional composition
The System
Function1
Desk
15
Function2
Table top
Studying
Function3
... ...
Filing cabinet Bookshelves
... ...
... ...
Function11
Function12
Left drawer
Middle drawer Right drawer
Functional (De)Composition
Modules
with well-defined semantics
that can be directly implemented.
Procedures own the data.
Data plays a secondary role.
Does not necessarily reflect the
states of abstraction in the
application.
16
Object-Orientation
 A thinking
methodology
 Everything
is an object.
 Any system is composed of objects (a system
is also an object).
 The evolution and development of a system
is caused by the interactions of the objects
inside/outside a system.
17
Everything is an object
A student, a professor
 A desk, a chair, a classroom, a building
 A university, a city, a country
 The world, the universe
 A subject such as CS, IS, Math, History, …

18
Systems are composed of
objects
 An
educational system
 An economic system
 An information system
 A computer system
19
The development of a system is
caused by interactions
 NJIT
is defined by the interactions
among:
 students
 professors
Inside NJIT
 staff
 Board
governance
 State governance
 … ...
20
Outside NJIT
Design Methodologies
 Object-Orientation
is a design
methodology(OOA/OOD)
 Objects
are the building blocks of a
program (interface, editor, menu, file,
etc.); data managing object (db), etc.)
 Objects represent real-world
abstractions within an application.
21
Design Methodologies
Object-orientation

induction: objects -> a class
This

needs tools
and deduction: a class ->objects
This
22
supports
needs programmers
Design Methodologies
Object-orientation
Top-down:
supports
from a super-class to sub-
classes
Bottom-up: from sub-classes to a
super-class
23
Programming Techniques
The
evolution of programming
techniques is
to
make languages more expressive
to control complex systems more
easily
24
Abstract Data Types(ADTs)
 Abstraction
 Properties
 Abstract
Data Types and ObjectOrientation
25
Abstraction
 to
understand a problem by
separating necessary from
unnecessary details
 To define the interface to a data
abstraction without specifying
implementation detail.
26
Abstraction
Problem
Model
27
Properties of ADT
 With
abstraction, you create a welldefined entity
 These entities define the data
structure as a set of items.
 For
example, each employee has a name,
date of birth, and social number...
28
Properties of ADT(Cont.)
 The
data structure can only be
accessed with defined operations.
 This
 An
set of operations is called the interface
entity with these properties is
called an abstract data type (ADT).
29
ADT
Abstract
Data Type
Abstract Data Structure
Interface
Operations
30
Definition (ADT)
 ADT
is characterized by the following
properties:
 1.
It exports a type.
 2. It exports a set of operations.
 3. Operations of the interface are the only
access mechanism to the data structure.
 4. Axioms and preconditions define the
application domain of the type.
31
Example: ADT List
 Type
List.
 The interface to instances of type List is
defined by the interface definition file.
 Operations: insert, get, append, delete,
search,…
32
List
 The
application domain is defined by the
semantical meaning of the provided
operations. Axioms and preconditions
include statements such as
 ``An
empty list is a list.''
 ``Let l=(d1, d2, d3, ..., dN) be a list. Then
l.append(dM) results in l=(d1, d2, d3, ..., dN,
dM).''
 ``an element of a list can only be deleted if the
list is not empty.''
33
Encapsulation
 Combines
the data and the operations
 Encloses both variables and functions
 Keeps details of data and operations
from the users of the ADT
34
Encapsulation (cont.)
 Allows
for modularity
 Controls access to data
 Separates implementation from
interface
 Extends the built-in types
35
Object-Oriented Programming
 Objects
are derived from ADTs.
 Interacting objects handle their own
house-keeping.
 Objects in a program interact by
sending messages to each other.
36
Object1
Data1+Procedures1
Object2
Data
Data
Data12
2 + Procedures
Object3
Data3 + Procedures3
Object4
Data4 + Procedures4
37
Object-Oriented Programming
Each
object is responsible to
initialize and destroy itself.
Therefore, there is no need to
explicitly call a creation or
termination procedure.
38
ADT and Object-Orientation
 ADTs
allow for the creation of instances
with well-defined properties and behavior.
 In object-orientation, ADTs are referred to
as classes.
 Therefore, a class defines the properties
of objects called instances.
39
ADT and Object-Orientation
 ADTs
define functionality by emphasizing the
involved data, their structure, operations,
axioms and preconditions.
 Object-oriented programming is
``programming with ADTs'': combining
functionality of different ADTs to solve a
problem.
 Therefore, instances (objects) of ADTs
(classes) are dynamically created, destroyed
and used.
40
Inheritance(Hierarchy)
 Expresses
commonality among objects
 Allows code reusability
 Highlights Generalization/Specialization
relationships
41
Polymorphism
The
ability of objects to
respond differently to the same
message or function call.
42
Object-Orientation Evolution
 Modules
 Information
hiding
 Data encapsulation
 Abstract data types
 Objects
43
Remember:
 Encapsulation
(Data & Operations)-- A
technique for Information Hiding. The
users of the objects do not need to
know the details of the data and
operations of the objects.
 Data Abstraction -- the procedure to
define a class from objects.
 Abstract Data Type-- Class.
44
Objects and Large Software
Systems
 Object
view
 Makes
systems more understandable
 Unifies design and programming
methods
 Initial program thoughts are informal
objects-and-interactions, even when
using non-OO languages.
45
Objects and Large Software Systems
Divides
code into logical chunks
Allows for "off-the-shelf" code libraries
to be reused
Supports code evolution: internals can
always be re-written as long as
interface stays the same
46
Reading


47
Chapter 1 Sections 1.1-1.2
Chapter 5 Sections 5.1-5.2