Object-Oriented Programming

ECE1112

November 2004 ECE1112/KOE-IIUM 1

 Admin. Course
Grades:
 Assignments : 5%
 Lab : 20%
 Quizzes: 10%
 Mid-term test: 30%
 Final Project : 10%
 Final Exam: 25%

Text Books:
 Required: 1. C++ How To Program (4 Ed.), Deitel & Deitel, Prentice Hall,

2003, ISBN 0-13-038474-7.

2. Introduction to Programming Using Java. An Object-Oriented
Approach, David Arnow/Gerald Weiss, Addison Wesley.
ISBN 0-201-61272-0
Recommended: 1. Understanding Object-Oriented Programming with Java,
Timothy Budd, Addison-Wesley.
ISBN 0201 78704 0

November 2004 ECE1112/KOE-IIUM 2

 A Survey of Programming Techniques

 Roughly speaking, we can distinguish the following learning curve of

someone who learns to program:

1. Unstructured Programming
2. Procedural Programming
3. Modular Programming
4. Object-Oriented Programming

November 2004 ECE1112/KOE-IIUM 3

 Unstructured Programming

 Usually, people start learning

programming by writing small
and simple programs
consisting only of one main
program.
 Here ``main program'' stands
for a sequence of commands
or statements which modify
data which is global
throughout the whole program
 This programming techniques
provide tremendous
disadvantages once the
program gets sufficiently large.

November 2004 ECE1112/KOE-IIUM 4

 Procedural Programming

 With procedural programming we are able to combine returning

sequences of statements into one single place.
 A procedure call is used to invoke the procedure.
 After the sequence is processed, flow of control proceeds right after
the position where the call was made.
 With introducing parameters as well as procedures of
procedures ( subprocedures) programs can now be written
more structured and error free.


A program can be viewed as a sequence of procedure calls

November 2004 ECE1112/KOE-IIUM 5

 Procedural Programming

To enable usage of general procedures or groups of procedures also in other

programs, they must be separately available.

For that reason, modular programming allows grouping of procedures into

modules.

November 2004 ECE1112/KOE-IIUM 6

 Modular Programming
 With modular programming
procedures of a common
functionality are grouped
together into separate modules.
 A program therefore no longer
consists of only one single part.
 It is now devided into several
smaller parts which interact
through procedure calls and
which form the whole program.
 Each module can have its own
data. This allows each module
to manage an internal state
which is modified by calls to
procedures of this module

November 2004 ECE1112/KOE-IIUM 7

 Modular Programming Problems

 Explicit Creation and Destruction.

In the example every time you want to use a list, you explicitly have
to declare a handle and perform a call to list_create() to obtain a
valid one. After the use of the list you must explicitly call
list_destroy() with the handle of the list you want to be destroyed.

 Decoupled Data and Operations.

Decoupling of data and operations leads usually to a structure based
on the operations rather than the data: Modules group common
operations (such as those list_...() operations) together.
In object-orientation, structure is organized by the data.

November 2004 ECE1112/KOE-IIUM 8

 Missing Type Safety
 Consider the following example which the compiler cannot check for
correctness:
PROCEDURE foo() BEGIN
SomeDataType data1;
SomeOtherType data2;
list_handle_t myList;
myList <- list_create();
list_append(myList, data1);
list_append(myList, data2); /* Oops */
...
list_destroy(myList);
END
A possible solution is to additionally add information about the type to each
list element.
However, this implies more overhead and does not prevent you
from knowing what you are doing.

November 2004 ECE1112/KOE-IIUM 9

 Object-Oriented Programming

 Object-oriented programming
solves some of the problems just
mentioned.
 In contrast to the other
techniques, we now have a web of
interacting objects, each house-
keeping its own state.
 Objects of the program
interact by sending messages
to each other.

November 2004 ECE1112/KOE-IIUM 10

 Object-Oriented Programming
 The problem here with modular programming is, that you must
explicitly create and destroy your list handles. Then you use the
procedures of the module to modify each of your handles.
 In contrast to that, in object-oriented programming we would have
as many list objects as needed.
 Instead of calling a procedure which we must provide with the
correct list handle, we would directly send a message to the list
object in question.
 Roughly speaking, each object implements its own module allowing
for example many lists to coexist.
 Consequently, there is no longer the need to explicitly call a creation
or termination procedure.
 So what? Isn't this just a more fancier modular programming
technique? Fortunately, it is not.

November 2004 ECE1112/KOE-IIUM 11

 Abstract Data Types

 Some authors describe object-

oriented programming as
programming abstract data types
and their relationships.
 Handling Problem =>
 This implies that the model
focusses only on problem related
stuff and that you try to define
properties of the problem.
 These properties include:
1. The data which are
affected and
2. The operations which
are identified

November 2004 ECE1112/KOE-IIUM 12

 Abstract Data Types (Contd.)
 As an example consider the administration of employees in an
institution.
 The head of the administration comes to you and ask you to create
a program which allows to administer the employees.
 Well, this is not very specific.
 For example, what employee information is needed by the
administration? What tasks should be allowed? Employees are real
persons who can be characterized with many properties.

Consequently you create a model of an employee for the problem.
 This model only implies properties which are needed to fulfill the
requirements of the administration, for instance name, date of birth
and social number.
 These properties are called the data of the (employee) model.

November 2004 ECE1112/KOE-IIUM 13

 Abstract Data Types (Contd.)
 Of course, the pure description is not enough. There must be some
operations defined with which the administration is able to handle
the abstract employees.
 For example, there must be an operation which allows you to create
a new employee once a new person enters the institution.
 Abstraction is the structuring of a nebulous problem into well-
defined entities by defining their data and operations.

Consequently, these entities combine data and operations.
 They are not decoupled from each other.

November 2004 ECE1112/KOE-IIUM 14

 Properties of Abstract Data Types
 Definition (Abstract Data Type) An abstract data type (ADT)
is characterized by the following properties:

1. It exports a type.

2. It exports a set of operations. This set is called interface.

3. Operations of the interface are the one and only access

mechanism to the type's data structure.

4. Axioms and preconditions define the application domain of the

type.

November 2004 ECE1112/KOE-IIUM 15

Abstract Data Types and Object-Orientation

 ADTs allows the creation of instances with well-defined properties

and behaviour.
 In object-orientation ADTs are referred to as classes.
 Therefore a class defines properties of objects which are the
instances in an object-oriented environment.
 ADTs define functionality by putting main emphasis on the involved
data, their structure and operations.
 Consequently, 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.

November 2004 ECE1112/KOE-IIUM 16

 Class
 A class is the implementation of an abstract data type (ADT). It defines
attributes and methods which implement the data structure and
operations of the ADT, respectively.
 Instances of classes are called objects.
 Consequently, classes define properties and behaviour of sets of objects.
 Example:
class Integer{
attributes:
int I
methods:
setValue(int n)
Integer addValue(Integer j)
}

November 2004 ECE1112/KOE-IIUM 17

 Object
 Recall the employee example on slide 13.
 We have talked of instances of abstract employees. 
 These instances are actual ``examples'' of an abstract employee,
hence, they contain actual values to represent a particular employee.
 We call these instances objects.

Definition: An object is an instance of a class. It can be uniquely

identified by its name and it defines a state which is represented by
the values of its attributes at a particular time.

 The state of the object changes according to the methods which are
applied to it.
 We refer to these possible sequence of state changes as the behaviour
of the object.

November 2004 ECE1112/KOE-IIUM 18

 Behavior
 Definition: The behaviour of an object is defined by the set of
methods which can be applied on it.
 We now have two main concepts of object-orientation introduced,
class and object.
 Object-oriented programming is therefore the implementation of
abstract data types or, in more simple words, the writing of classes.
 At runtime instances of these classes, the objects, achieve the goal
of the program by changing their states.
 Consequently, you can think of your running program as a collection
of objects.

The question arises of how these objects interact?
 We therefore introduce the concept of a message in the next
section.

November 2004 ECE1112/KOE-IIUM 19

 Message and Method

 A running program is a pool of objects where objects are created,

destroyed and interacting.
 This interacting is based on messages which are sent from one
object to another asking the recipient to apply a method on itself.
 Definition: A message is a request to an object to invoke one of
its methods.
 A message therefore contains:
1. The name of the method.
2. The arguments of the method.

Definition: A method is associated with a class. An object

invokes a method as a reaction to receipt of a message.

November 2004 ECE1112/KOE-IIUM 20