CIS601: Object-Oriented

Programming in C++
Lesson #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: [email protected]
Web: www.ccs.njit.edu/maura

Goals for the Course

To understand

Object Oriented

programming
To further develop your C++ skills

Course Coverage

Fundamentals of object-oriented
programming
*Data abstraction
*Encapsulation
*Inheritance
*Dynamic binding
*Polymorphism

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.

Course Coverage cont.

Effects of OO methodology on software

design
maintenance
extensibility
reusability

Prerequisites

Working knowledge of
C/C++
Familiarity

with operating systems

Familiarity with compilers

Lectures

1. Introduction to Object-Oriented
Programming

2. Overview of basic structures of C++

3. Objects and Classes
4. Objects and Classes in C++
5. Inheritance
6. Inheritance in C++
7. Polymorphism and That in C++

Lectures cont.

8. Operator Overloading in C++

9. 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

Thinking Methodology
Induction
From

specialization to generalization

to

create the word dog from different

dogs
Dog

10

Thinking Methodology
Deduction(infer)
From

generalization to specialization

From

the word dog you have learned

that an animal is or is not a dog.

DOG

11

Design Methodologies

Functional decomposition (Top-Down)

The

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

Studying

Table top

Function3

... ...

Filing cabinet Bookshelves

... ...

... ...

Function11

Function12

Left drawer

Middle drawer Right drawer

Design Methodologies

Functional composition (bottom-up)

To

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

Studying

Table top

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

18

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,

Systems are composed of

objects

19

An educational system
An economic system
An information system
A computer system

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

29

set of operations is called the interface

An entity with these properties is

called an abstract data type (ADT).

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

33

``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.''

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

40

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.

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