470 likes | 554 Views
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: maura.a.deek@njit.edu Web: www.ccs.njit.edu/maura. Goals for the Course.
E N D
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: maura.a.deek@njit.edu 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
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
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.
Functional decomposition The System Studying Function1 Function2 Function3 . . . . . . Desk Table top 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.
Functional composition The System Studying Function1 Function2 Function3 . . . . . . Desk Table top 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.
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.
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, …
Systems are composed of objects • 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 • staff • Board governance • State governance • … ... Inside NJIT 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.
Design Methodologies • Object-orientation supports • induction: objects -> a class • This needs tools • and deduction: a class ->objects • This needs programmers
Design Methodologies • Object-orientation supports • Top-down: from a super-class to sub-classes • Bottom-up: from sub-classes to a super-class
Programming Techniques • The evolution of programming techniques is • to make languages more expressive • to control complex systems more easily
Abstract Data Types(ADTs) • Abstraction • Properties • Abstract Data Types and Object-Orientation
Abstraction • to understand a problem by separating necessary from unnecessary details • To define the interface to a data abstraction without specifying implementation detail.
Abstraction Problem Model
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...
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).
ADT Abstract Data Type Abstract Data Structure Interface Operations
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.
Example: ADT List • TypeList. • The interface to instances of type List is defined by the interface definition file. • Operations: insert, get, append, delete, search,…
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.''
Encapsulation • Combines the data and the operations • Encloses both variables and functions • Keeps details of data and operations from the users of the ADT
Encapsulation (cont.) • Allows for modularity • Controls access to data • Separates implementation from interface • Extends the built-in types
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.
Object1 Data1+Procedures1 Object2 Data2 +Procedures2 Data Data1 Object3 Data3 +Procedures3 Object4 Data4 +Procedures4
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.
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.
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.
Inheritance(Hierarchy) • Expresses commonality among objects • Allows code reusability • Highlights Generalization/Specialization relationships
Polymorphism • The ability of objects to respond differently to the same message or function call.
Object-Orientation Evolution • Modules • Information hiding • Data encapsulation • Abstract data types • Objects
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.
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.
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
Reading • Chapter 1 Sections 1.1-1.2 • Chapter 5 Sections 5.1-5.2