1

CIS601: Object-Oriented Programming in C++

Note: CIS 601 notes were originally developed by H. Zhu for NJIT DL Program. The notes were subsequently revised by M. Deek.

Lesson #1

2

Contact Information

Email: maura.a.deek@njit.edu

Web: www.ccs.njit.edu/maura

3

Goals for the Course

To understand Object Oriented programming

To further develop your C++ skills

4

Course Coverage Fundamentals of object-oriented

programming*Data abstraction

*Encapsulation

*Inheritance

*Dynamic binding

*Polymorphism

5

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.

6

Effects of OO methodology on software design maintenance extensibility reusability

Course Coverage cont.

7

Prerequisites Working knowledge of

C/C++ Familiarity with operating systems Familiarity with compilers

8

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

9

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

10

Thinking Methodology

Induction From specialization to generalization

to create the word “dog” from different dogs

Dog

11

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

12

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.

13

Functional decomposition

The System

Function1 Function2 Function3

Function11 Function12

. . . . . .

. . . . . .

. . . . . .

Studying

Desk Table top Filing cabinet Bookshelves

Left drawer Middle drawer Right drawer

14

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.

15

Functional composition

The System

Function1 Function2 Function3

Function11 Function12

. . . . . .

. . . . . .

. . . . . .

Studying

Desk Table top Filing cabinet Bookshelves

Left drawer Middle drawer Right drawer

16

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.

17

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 i

s caused by the interactions of the objects inside/outside a system.

18

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, …

19

Systems are composed of objects

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

20

The development of a system is caused by interactions

NJIT is defined by the interactions among: students professors staff Board governance State governance … ...

Inside NJIT

Outside NJIT

21

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.

22

Design Methodologies

Object-orientation supports induction: objects -> a class

This needs tools and deduction: a class ->objects

This needs programmers

23

Design Methodologies

Object-orientation supports Top-down: from a super-class to sub-

classes Bottom-up: from sub-classes to a sup

er-class

24

Programming Techniques

The evolution of programming techniques is to make languages more expressive to control complex systems more

easily

25

Abstract Data Types(ADTs)

Abstraction Properties Abstract Data Types and Object-

Orientation

26

Abstraction

to understand a problem by separating necessary from unnecessary details

To define the interface to a data abstraction without specifying implementation detail.

27

Problem

Model

Abstraction

28

Properties of ADT With abstraction, you create a well-

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

29

Properties of ADT(Cont.)

The data structure can only be accessed with defined operations. This set of operations is called the interface

An entity with these properties is called an abstract data type (ADT).

30

Interface

Operations

Abstract Data Structure

Abstract Data Type

ADT

31

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.

32

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,…

33

List The application domain is defined by the s

emantical 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.app

end(dM) results in l=(d1, d2, d3, ..., dN, dM).'' ``an element of a list can only be deleted if the l

ist is not empty.''

34

Encapsulation

Combines the data and the operations Encloses both variables and functions Keeps details of data and operations

from the users of the ADT

35

Encapsulation (cont.)

Allows for modularity Controls access to data Separates implementation from

interface Extends the built-in types

36

Object-Oriented Programming

Objects are derived from ADTs. Interacting objects handle their own ho

use-keeping. Objects in a program interact by sendin

g messages to each other.

37

Object1

Data1+Procedures1

Data Data1 Object3

Data3 + Procedures3

Object2

Data2 + Procedures2

Object4

Data4 + Procedures4

38

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.

39

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.

40

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.

41

Inheritance(Hierarchy)

Expresses commonality among objects Allows code reusability Highlights Generalization/Specialization

relationships

42

Polymorphism

The ability of objects to respond differently to the same message or function call.

43

Modules Information hiding Data encapsulation Abstract data types Objects

Object-Orientation Evolution

44

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.

45

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.

Objects and Large Software Systems

46

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

47

Reading

Chapter 1 Sections 1.1-1.2 Chapter 5 Sections 5.1-5.2