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 Web:

3 Goals for the Course u To understand Object Oriented programming u To further develop your C++ skills

4 Course Coverage u Fundamentals of object-oriented programming *Data abstraction *Encapsulation *Inheritance *Dynamic binding *Polymorphism

5 u C++ will be used as a vehicle to illustrate and implement OOP concepts. u Object-oriented paradigm will be applied to design and programming. Course Coverage cont.

6 u Effects of OO methodology on software design u maintenance u extensibility u reusability Course Coverage cont.

7 Prerequisites u Working knowledge of u C/C++ u Familiarity with operating systems u Familiarity with compilers

8 Lectures u 1. Introduction to Object-Oriented Programming u 2. Overview of basic structures of C++ u 3. Objects and Classes u 4. Objects and Classes in C++ u 5. Inheritance u 6. Inheritance in C++ u 7. Polymorphism and That in C++

9 Lectures cont. u 8. Operator Overloading in C++ u 9. Templates and Friends in C++ u 10. I/O Streams in C++ u 11. Exception Handling in C++ u 12. Container Classes in C++ u 13. Object-Oriented Analysis and Design u 14. Case Studies and Review

10 Thinking Methodology u Induction u From specialization to generalization u to create the word “dog” from different dogs Dog

11 Thinking Methodology u Deduction(infer) u From generalization to specialization u From the word “dog” you have learned that an animal is or is not a dog. DOG

12 Design Methodologies u Functional decomposition (Top-Down) u 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 Function1Function2Function3 Function11Function12... Studying DeskTable topFiling cabinetBookshelves Left drawerMiddle drawerRight drawer

14 Design Methodologies u Functional composition (bottom-up) u To create different components of a function from a library of functions. u To integrate components into a module and form a more significant function.

15 Functional composition The System Function1Function2Function3 Function11Function12... Studying DeskTable topFiling cabinetBookshelves Left drawerMiddle drawerRight drawer

16 Functional (De)Composition u Modules with well-defined semantics that can be directly implemented. u Procedures own the data. u Data plays a secondary role. u Does not necessarily reflect the states of abstraction in the application.

17 Object-Orientation u A thinking methodology u Everything is an object. u Any system is composed of objects (a system is also an object). u The evolution and development of a system is caused by the interactions of the objects inside/outside a system.

18 Everything is an object u A student, a professor u A desk, a chair, a classroom, a building u A university, a city, a country u The world, the universe u A subject such as CS, IS, Math, History, …

19 Systems are composed of objects u An educational system u An economic system u An information system u A computer system

20 The development of a system is caused by interactions u NJIT is defined by the interactions among: u students u professors u staff u Board governance u State governance u …... Inside NJIT Outside NJIT

21 Design Methodologies u Object-Orientation is a design methodology(OOA/OOD) u Objects are the building blocks of a program (interface, editor, menu, file, etc.); data managing object (db), etc.) u Objects represent real-world abstractions within an application.

22 Design Methodologies u Object-orientation supports u induction: objects -> a class u This needs tools u and deduction: a class ->objects u This needs programmers

23 Design Methodologies u Object-orientation supports u Top-down: from a super-class to sub- classes u Bottom-up: from sub-classes to a super-class

24 Programming Techniques u The evolution of programming techniques is u to make languages more expressive u to control complex systems more easily

25 Abstract Data Types(ADTs) u Abstraction u Properties u Abstract Data Types and Object- Orientation

26 Abstraction u to understand a problem by separating necessary from unnecessary details u To define the interface to a data abstraction without specifying implementation detail.

27 Problem Model Abstraction

28 Properties of ADT u With abstraction, you create a well- defined entity u These entities define the data structure as a set of items. u For example, each employee has a name, date of birth, and social number...

29 Properties of ADT( Cont.) u The data structure can only be accessed with defined operations. u This set of operations is called the interface u 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) u ADT is characterized by the following properties: u 1. It exports a type. u 2. It exports a set of operations. u 3. Operations of the interface are the only access mechanism to the data structure. u 4. Axioms and preconditions define the application domain of the type.

32 Example: ADT List u Type List. u The interface to instances of type List is defined by the interface definition file. u Operations: insert, get, append, delete, search,…

33 List u The application domain is defined by the semantical meaning of the provided operations. Axioms and preconditions include statements such as u ``An empty list is a list.'' u ``Let l=(d1, d2, d3,..., dN) be a list. Then l.append(dM) results in l=(d1, d2, d3,..., dN, dM).'' u ``an element of a list can only be deleted if the list is not empty.''

34 Encapsulation u Combines the data and the operations u Encloses both variables and functions u Keeps details of data and operations from the users of the ADT

35 Encapsulation (cont.) u Allows for modularity u Controls access to data u Separates implementation from interface u Extends the built-in types

36 Object-Oriented Programming u Objects are derived from ADTs. u Interacting objects handle their own house-keeping. u Objects in a program interact by sending messages to each other.

37 Object 1 Data 1 +Procedures 1 DataData 1 Object 3 Data 3 + Procedures 3 Object 2 Data 2 + Procedures 2 Object 4 Data 4 + Procedures 4

38 Object-Oriented Programming u Each object is responsible to initialize and destroy itself. u Therefore, there is no need to explicitly call a creation or termination procedure.

39 ADT and Object-Orientation u ADTs allow for the creation of instances with well-defined properties and behavior. u In object-orientation, ADTs are referred to as classes. u Therefore, a class defines the properties of objects called instances.

40 ADT and Object-Orientation u ADTs define functionality by emphasizing the involved data, their structure, operations, axioms and preconditions. u Object-oriented programming is ``programming with ADTs'': combining functionality of different ADTs to solve a problem. u Therefore, instances (objects) of ADTs (classes) are dynamically created, destroyed and used.

41 Inheritance(Hierarchy) u Expresses commonality among objects u Allows code reusability u Highlights Generalization/Specialization relationships

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

43 u Modules u Information hiding u Data encapsulation u Abstract data types u Objects Object-Orientation Evolution

44 Remember: u 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. u Data Abstraction -- the procedure to define a class from objects. u Abstract Data Type-- Class.

45 u Object view u Makes systems more understandable u Unifies design and programming methods u 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 u Divides code into logical chunks u Allows for "off-the-shelf" code libraries to be reused u Supports code evolution: internals can always be re-written as long as interface stays the same

47 Reading u Chapter 1 Sections u Chapter 5 Sections