Contents Differences of OOP from procedural programming Chapter 1. - PowerPoint PPT Presentation

Contents  Differences of OOP from procedural programming Chapter 1. Introduction to Objects  Overview of OOP features and some C++ features  Some basic UML notations C++ Object Oriented Programming Pei-yih Ting  Analysis and Design methodologies NTOUCS  Extreme Programming Features  Why C++ succeeds 1 2 OOP vs. Procedural Programming OOP vs. Procedural (cont’d)  It is now changing gradually: tools are beginning to look less like machines and more like parts of  Hardware improvements mark the revolution of our minds or daily lives --- much more accessible computer technology in the past 40 + years. to general public (ex. Desktop metaphor, Document center…)  Procedural programming:  Object-Oriented Programming (OOP) is part of you program tends to control directly the this movement toward using the computer as an underlying machine, which is mostly built expressive medium. with the von Neuman architecture 3 4

Progress of Abstraction Progress of Abstraction (cont’d)  All (programming) languages provide abstractions. model in the underlying model in the programmer machine (arrays, loops…)  abstraction: you transform your physical problem into a problem domain (people, teacher, description in some other media manager,staff, tough times with black coffee data store, utility and cigarettes  problem statement, machine language, assembly language, tools ……) imperative languages (Fortran, BASIC, C, PASCAL,  Good programmers do the mapping faster, with less COBOL…), functional languages (LISP, ML, Scheme…), errors, and produce better structured codes. declarative languages (PROLOG, GPSS…), object-oriented languages (SIMULA, Smalltalk, Eiffel, C++, Java…)  Programmers need to know exactly the operating mechanisms of the underlying machines.  Assembly and Imperative Language:  Often:  abstraction requires you think in terms of the structure of the  the mapping mechanism are too complex to be documented computer (solution space) rather than the structure of the well or even thrown away completely problem (problem space)  result programs are expensive to maintain 5 6 Progress of Abstraction (cont’d) Progress of Abstraction (cont’d)  Functional, Declarative, and 4-th Gen. languages:  Object-Oriented Programming (Analysis/Design)  Each programming languages choose particular views of the  Programmer represents elements in the problem space directly. world  OOP minimizes transformations a programmer need to do on the  “all problems are ultimately lists” in LISP original problem in order to let the computer solve it.  “all problems are algorithmic” in APL  OOPL is not constrained to any particular type of problem.  “all problems are logical production rules” in PROLOG  Describe all elements in the problem space as “objects”  “all problems are math equations” in Mathematica (although a programmer still has some auxiliary abstract objects  “all problems are descriptive words” in WORD that have no correspondence in the physical problem domain).  “all problems can be manipulated with graphical symbols”  When you read the codes describing the solution, you are in some visual languages reading words that also express the problem. You don’t need  Each of these approaches is a good solution to the particular those “transformation guidelines invented by any programmer”. class of problem it is designed to solve. The code is not a bunch of CPU/Memory/IO operations.  When you step outside of that domain, it becomes awkward. 7 8

Progress of Abstraction (cont’d) Algorithmic vs. OO Decomposition  Objects …. The fundamental ingredients in OOP.  In summary:  attributes/properties/states/data  Procedural programming: algorithmic decomposition  behaviors : answering requests (messages) or functional decomposition of the problem, the  Five basic characteristics of Smalltalk -- a pure OOPL software is viewed as a process 1. Everything is an object  Object Oriented programming: decompose the 2. A program is a bunch of objects telling each other what to do by problem into a set of well-defined objects, functional sending messages decomposition is addressed after the system has been 3. Each object has its own memory (probably made up of other decomposed into objects (i.e. on top of objects) objects)  decomposition is more intuitive 4. Every object has a type (instance/class) …. classification  encourage the reuse of objects 5. All objects of a particular type can receive the same messages  emphasize the encapsulation at each level also, an object of type “circle” is also an object of type “shape” substitutability is one of the most powerful concepts in OOP. 9 10 Overview of OOP features Class and Object  class : objects that have common characteristics and  An object has an interface behaviors … types, abstract data types  The hidden implementation (Encapsulation)  user defined, works almost exactly like built-in data types  Reusing the implementation: hierarchy  ex.  Bank account: balance/deposit/withdraw...  Reusing the interface: inheritance  Alarm clock characteristics/attributes/properties/data  TV set  Is-a vs. is-like-a relationships behaviors/functionality  ATM  Interchangeable objects with polymorphism  objects/variables/instances  creation: using the class as a template  Creating and destroying objects  manipulation: sending messages or requests  Exception handling: dealing with errors  a programmer defines a class to fit a problem rather than efficiently being forced to use existing data types 11 12

Object has Interface Encapsulation  Interface:  class creator: those who create/maintain new data types client programmer: the class/object consumers who use  the interface establishes requests that you can make for a particular class of objects the new data types in their applications type name Light  Implementation details are intended to be hidden from all on() The services Light client programmers except the class creator. objects provide. off() interface  Integrity of the internal state of an object can be maintained. brighten() dim()  Class creator can change the hidden portion at will without  Send a message (make a request): breaking the contract – the interface. Light light;  Reduce program bugs: client programmer tends to bypass the light.on(); UML notation official contract promised by the interface and make very good  Implementation: void Light::on() use of every aspect of an existing code implementation. { // do something  Enforced through access control: public/protected/private } 13 14 Reusing the Implementation Inheritance  Code reuse is one of the greatest advantages that OOPL  Inheritance: take an existing class, clone it, and provide. then make modifications or additions to the clone.  A class can have multiple instances.  Base class / super class / parent class vs.  Build up hierarchies: avoid reinventing wheels Derived class / sub class / child class / inherited class  composition  Three things are inherited by the derived class : class Country { interfaces, implementations (data and functionality), and Country President private: relationships President m_president; };  aggregation Animal Vehicle Employee Window class Car { Car Engine private: Engine *m_engine; }; Dog Car Manager Dialog Note: hierarchical structure in this way is flexible, can be dynamically changed at run time 15 16

Reusing the Implementation Reusing the Interface  You use inheritance if you want  inheritance Shape Shape your objects of the Triangle class class Shape class Triangle : public Shape { { be handled by client programs …. …. }; }; exactly the same as if they were Triangle Circle Triangle objects of the Shape class. Note: 1. codes and data can be reused (From the point of view of client programmers, these 2. static reuse, determined at compile time two types of objects are indistinguishable. They are completely substitutable in the sense that they all CAVEAT: Because inheritance is important in object-oriented programming, it is often over-emphasized. New OOP provide the same Shape interface.) programmers can get the incorrect idea that inheritance  Why do people like to ignore the differences between a should be used everywhere. This is not true. Always triangle object and a circle object and call them Shape consider composition first when creating classes, since objects? in order to simplify the handling mechanism it is simpler and more flexible. 17 18 Reusing the Interface (cont’d) Reusing the interface Shape trash recycling CAD Canvas draw() machine exploit garbage erase() “interface reusing” move() truck getColor() mechanism of exploit “interface reusing” setColor() trash “old codes call new codes” Circle Square Triangle aluminum bottle steel can can  All the interfaces (messages) are inherited by child  Trash recycling machine can process all three classes classes. All the code implementations (message (bottle, aluminum can, and steel can) in one unified way. handling mechanisms) are also inherited by default if  Does this model capture the essence of real world model? you do not modify them. 19 20