Introduction to Object Oriented Programming Lecture-3.

18
Introduction to Object Oriented Programming Lecture-3

Transcript of Introduction to Object Oriented Programming Lecture-3.

Page 1: Introduction to Object Oriented Programming Lecture-3.

Introduction to Object Oriented Programming

Lecture-3

Page 2: Introduction to Object Oriented Programming Lecture-3.

Programming Techniques

Unstructured Programming Procedural Programming Modular Programming Object Oriented Programming

Page 3: Introduction to Object Oriented Programming Lecture-3.

Unstructured Programming

The first step into programming Hello World program as seen below However difficult to manage once the program

gets large > 100 lines?

#include <iostream>using namespace std;int main(void){ cout << “Hello World” << endl; return 0;}

Page 4: Introduction to Object Oriented Programming Lecture-3.

Procedural Programming

Divide program into smaller blocks of code These may then be called more than once Makes program more structured (and less prone

to errors) Allows programs to be designed to show a flow

of Data where data is passed from the main program into the procedures

Page 5: Introduction to Object Oriented Programming Lecture-3.

Procedural Programming

#include <iostream>using namespace std;

double calculate_new(double);int main(void){ double prices[] = 54,312,78,654,65,18; for(i=0; i<6; i++)

{ double newprice = calculate_new(price[i]);

cout << “New price for item “ << i<< “= “ << newprice << endl;}

return 0;}

double calculate_new( double oldprice){

return 0.70*oldprice;}

Page 6: Introduction to Object Oriented Programming Lecture-3.

Modular Programming

Procedures of common functionality are grouped into separate modules

Each module can have it's own data Each module can maintain an internal state However the module may exist at most once in

each program Structure of modular programs dictated by

functions not data Programs compiled into different modules so we

use a makefile to control the process (or ide based system which manages the project)

Page 7: Introduction to Object Oriented Programming Lecture-3.

Why Object Oriented Programming

Previously data effectively global to the program This leads to errors

Increasing size of programs make maintenance difficult (sometimes impossible)

Inter / intra project communication problems (teams of developers using different modules to do the same thing)

Software re-use

Page 8: Introduction to Object Oriented Programming Lecture-3.

But What is OO (the world as objects)

Systems are modelled as sets of interacting objects

Proponents claim that Object Orientation Is intuitive and abstract Manages Complexity Aids communication Scales up to large systems Allows consistent representation throughout the

lifecycle phases

Page 9: Introduction to Object Oriented Programming Lecture-3.

What is an Object

A tangible or visible 'thing' e.g. a person 'An object represents an individual identifiable

item, unit or entity, either real or abstract, with a well defined role in the problem domain'

This is good news for graphics programming as most things we want to design are objects or things that act on objects (e.g. a Shape is an abstract object which can be realised into a more concrete objects such as sphere, cube cone etc.)

Page 10: Introduction to Object Oriented Programming Lecture-3.

Object Structure

What Defines an Object ? A boundary e.g. a car body or building exterior An internal state e.g. Blood pressure, waiting Behavior -- what it does A Unique identity (as with instances, entities or

roles)

Page 11: Introduction to Object Oriented Programming Lecture-3.

Objects have boundaries

Physical Boundaries Skin, hull, surface, volume

Conceptual Boundaries 'Crisp' well defined e.g. sphere, cube, plane 'fuzzy' e.g. a river, a chemical process,

deformation

Page 12: Introduction to Object Oriented Programming Lecture-3.

Objects have states and behaviour

State : Static properties - inherit features or characteristics. e.g. height, volume, width,

State: Dynamic values - assigned to a feature e.g. colour, level of detail, position

Behavior is how an object acts and reacts An object may support 'services' that are

invoked when a message is sent an object may invoke 'services' in other

objects by passing a message to the object

Page 13: Introduction to Object Oriented Programming Lecture-3.

What is an Object

Shape

colordraw()erase()move()getColor()setColor()

Object

Identity

state

behaviour

Page 14: Introduction to Object Oriented Programming Lecture-3.

Key OO Concepts

There are 4 'pillars' or key concepts to OO these are Abstraction Encapsulation Modularity Hierarchy

Page 15: Introduction to Object Oriented Programming Lecture-3.

Abstraction

Two abstract conceptualisations of a PC An Intel based processor with peripherals A box that runs programs

“An abstraction denotes the essential characteristics of an object that distinguishes it from all other kinds of objects and thus provides crisply defined conceptual boundaries, relative to the perspective of the viewer”

Page 16: Introduction to Object Oriented Programming Lecture-3.

Encapsulation

An Object supports 'Visible' services defined in an interface. 'Hidden' state defined inside the object

The state of an object may only be accessed through the services supported in the object interface.

However as we shall see when we look at the code we can ignore this (and usually do in graphics programming as we need speed)

'Encapsulation serves to separate the conceptual interface of an abstraction and its implementation'

Page 17: Introduction to Object Oriented Programming Lecture-3.

Modularity

An object is a data centred module, with encapsulated state and behavior that operates on that state.

Objects communicate through message passing. This raises the following issues :

Deriving objects from the problem domain building 'well-engineered' objects Connecting objects in a meaningful way

Page 18: Introduction to Object Oriented Programming Lecture-3.

Hierarchy

Hierarchy is a ranking and ordering of abstractions

Two hierarchical schemes in OO : 'Is part of' - the object is a part of a larger object

e.g. Engine is part of a car

'Is a' is also known as 'inheritance' we can see this when looking at the hyper-

graph in Maya showing how all the different objects in a scene are connected together (especially when using groups).