4 Object-Oriented Concepts

The previous sections already introduce some ``object-oriented'' concepts. However, they
were applied in an procedural environment or in a verbal manner. In this section we
investigate these concepts in more detail and give them names as used in existing object-
oriented programming languages.

4.1 Implementation of Abstract Data Types

The last section introduces abstract data types (ADTs) as an abstract view to define
properties of a set of entities. Object-oriented programming languages must allow to
implement these types. Consequently, once an ADT is implemented we have a particular
representation of it available.

Consider again the ADT Integer. Programming languages such as Pascal, C, Modula-2
and others already offer an implementation for it. Sometimes it is called int or integer.
Once you've created a variable of this type you can use its provided operations. For
example, you can add two integers:

int i, j, k; /* Define three integers */

i = 1; /* Assign 1 to integer i */
j = 2; /* Assign 2 to integer j */
k = i + j; /* Assign the sum of i and j to k */

Let's play with the above code fragment and outline the relationship to the ADT Integer.
The first line defines three instances i, j and k of type Integer. Consequently, for each
instance the special operation constructor should be called. In our example, this is
internally done by the compiler. The compiler reserves memory to hold the value of an
integer and ``binds'' the corresponding name to it. If you refer to i you actually refer to
this memory area which was ``constructed'' by the definition of i. Optionally, compilers
might choose to initialize the memory, for example, they might set it to 0 (zero).

The next line

i = 1;

sets the value of i to be 1. Therefore we can describe this line with help of the ADT
notation as follows:

Perform operation set with argument 1 on the Integer instance i. This is written as
follows: i.set(1).
We now have a representation at two levels. The first level is the ADT level where we
express everything that is done to an instance of this ADT by the invocation of defined
operations. At this level, pre- and postconditions are used to describe what actually
happens. In the following example, these conditions are enclosed in curly brackets.

{ Precondition: i = n where n is any Integer }

i.set(1)
{ Postcondition: i = 1 }
Don't forget that we currently talk about the ADT level! Consequently, the conditions are
mathematical conditions.

The second level is the implementation level, where an actual representation is chosen for
the operation. In C the equal sign ``='' implements the set() operation. However, in Pascal
the following representation was chosen:

i := 1;

In either case, the ADT operation set is implemented.

Let's stress these levels a little bit further and have a look at the line

k = i + j;

Obviously, ``+'' was chosen to implement the add operation. We could read the part ``i +
j'' as ``add the value of j to the value of i'', thus at the ADT level this results in

{ Precondition: Let i = n1 and j = n2 with n1, n2 particular Integers }

i.add(j)
{ Postcondition: i = n1 and j = n2 }
The postcondition ensures that i and j do not change their values. Please recall the
specification of add. It says that a new Integer is created the value of which is the sum.
Consequently, we must provide a mechanism to access this new instance. We do this with
the set operation applied on instance k:

{ Precondition: Let k = n where n is any Integer }

k.set(i.add(j))
{ Postcondition: k = i + j }
As you can see, some programming languages choose a representation which almost
equals the mathematical formulation used in the pre- and postconditions. This makes it
sometimes difficult to not mix up both levels.

4.2 Class
 A class is an actual representation of an ADT. It therefore provides implementation
details for the data structure used and operations. We play with the ADT Integer and
design our own class for it:
class Integer {
attributes:
int i

methods:
setValue(int n)
Integer addValue(Integer j)
}

In the example above as well as in examples which follow we use a notation which is not
programming language specific. In this notation class {...} denotes the definition of a
class. Enclosed in the curly brackets are two sections attributes: and methods: which
define the implementation of the data structure and operations of the corresponding ADT.
Again we distinguish the two levels with different terms: At the implementation level we
speak of ``attributes'' which are elements of the data structure at the ADT level. The same
applies to ``methods'' which are the implementation of the ADT operations.

In our example, the data structure consists of only one element: a signed sequence of
digits. The corresponding attribute is an ordinary integer of a programming language .
We only define two methods setValue() and addValue() representing the two operations
set and add.

Definition (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.

4.3 Object
Recall the employee example of chapter 3. 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.

Objects are uniquely identifiable by a name. Therefore you could have two
distinguishable objects with the same set of values. This is similar to ``traditional''
programming languages where you could have, say two integers i and j both of which
equal to ``2''. Please notice the use of ``i'' and ``j'' in the last sentence to name the two
integers. We refer to the set of values at a particular time as the state of the object.

Definition (Object) 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:

Definition (Behaviour) 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.

4.4 Message
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. To give you an understanding of
this communication, let's come back to the class Integer presented in section 4.2. In our
pseudo programming language we could create new objects and invoke methods on them.
For example, we could use
Integer i; /* Define a new integer object */
i.setValue(1); /* Set its value to 1 */

to express the fact, that the integer object i should set its value to 1. This is the message
``Apply method setValue with argument 1 on yourself.'' sent to object i. We notate the
sending of a message with ``.''. This notation is also used in C++; other object-oriented
languages might use other notations, for example ``- ''.

Sending a message asking an object to apply a method is similar to a procedure call in

``traditional'' programming languages. However, in object-orientation there is a view of
autonomous objects which communicate with each other by exchanging messages.
Objects react when they receive messages by applying methods on themselves. They also
may deny the execution of a method, for example if the calling object is not allowed to
execute the requested method.

In our example, the message and the method which should be applied once the message is
received have the same name: We send ``setValue with argument 1'' to object i which
applies ``setValue(1)''.

Definition (Message) A message is a request to an object to invoke one of its methods. A

message therefore contains

• the name of the method and

• the arguments of the method.
Consequently, invocation of a method is just a reaction caused by receipt of a message.
This is only possible, if the method is actually known to the object.

Definition (Method) A method is associated with a class. An object invokes a method as

a reaction to receipt of a message.

4.5 Summary
To view a program as a collection of interacting objects is a fundamental principle in
object-oriented programming. Objects in this collection react upon receipt of messages,
changing their state according to invocation of methods which might cause other
messages sent to other objects. This is illustrated in Figure 4.1.

Figure 4.1: A program consisting of four objects.

In this figure, the program consists of only four objects. These objects send messages to
each other, as indicated by the arrowed lines. Note that the third object sends itself a
message.

class [klɑːs]
n
1. a collection or division of people or things sharing a common characteristic, attribute, quality, or
property
2. (Sociology) a group of persons sharing a similar social position and certain economic, political,
and cultural characteristics
3. (Philosophy) (in Marxist theory) a group of persons sharing the same relationship to the means
of production
4. (Sociology)
a. the pattern of divisions that exist within a society on the basis of rank, economic status, etc.
b. (as modifier) the class struggle class distinctions
5. (Social Science / Education)
a. a group of pupils or students who are taught and study together
b. a meeting of a group of students for tuition
6. (Social Science / Education) Chiefly US a group of students who graduated in a specified year
the class of '53
7. (Social Science / Education) (in combination and as modifier) Brit a grade of attainment in a
university honours degree second-class honours
8. one of several standards of accommodation in public transport See also first class, second
class, third class
9.

at·trib·ute ( -tr b y t)
tr.v. at·trib·ut·ed, at·trib·ut·ing, at·trib·utes
1. To relate to a particular cause or source; ascribe: attributed their failure to a lack of
preparation.
2. To regard as the work of a specified agent, place, or time: attributed the painting to Titian;
attributed the vase to 18th-century Japan.
n. at·tri·bute ( t r -by t )
1. A quality or characteristic inherent in or ascribed to someone or something.
2. An object associated with and serving to identify a character, personage, or office: Lightning
bolts are an attribute of Zeus

Encapsulation---

In a programming language encapsulation is used to refer to one of two related but

distinct notions, and sometimes to the combination[1][2] thereof:

• A language mechanism for restricting access to some of the object's components.

[3][4]

• A language construct that facilitates the bundling of data with the methods (or
other functions) operating on that data.[5][6]

Some programming language researchers and academics use the first meaning alone or in
combination with the second as a distinguishing feature of object oriented programming,
while other programming languages which provide lexical closures view encapsulation as
a feature of the language orthogonal to object orientation.
The second definition is motivated by the fact that in many OOP languages hiding of
components is not automatic or can be overridden; thus information hiding is defined as a
separate notion by those who prefer the second definition.

Inheritance----

In object-oriented programming (OOP), inheritance is a way to compartmentalize and

reuse code by creating collections of attributes and behaviors called objects which can be
based on previously created objects. In classical inheritance where objects are defined by
classes, classes can inherit other classes. The new classes, known as subclasses (or
derived classes), inherit attributes and behavior of the pre-existing classes, which are
referred to as superclasses (or ancestor classes). The inheritance relationships of classes
gives rise to a hierarchy. In prototype-based programming, objects can be defined directly
from other objects without the need to define any classes, in which case this feature is
called differential inheritance.

The inheritance concept was invented in 1967 for Simula.[1]

Polymorphism--

Subtype polymorphism, almost universally called just polymorphism in the context of

object-oriented programming, is the ability to create a variable, a function, or an object
that has more than one form. The word derives from the Greek "πολυμορφισμός"
meaning "having multiple forms". This article is an accessible introduction to the topic,
which restricts attention to the object-oriented paradigm. The purpose of polymorphism is
to implement a style of programming called message-passing in the literature[citation needed],
in which objects of various types define a common interface of operations for users.

In strongly typed languages, polymorphism usually means that type A somehow derives
from type B, or type C implements an interface that represents type B. In weakly typed
languages types are implicitly polymorphic.
Object oriented /w project----

So far, we have only considered individual classes and some low-level

design issues,
such as where the data members should go in a C++ class, why
constructors are
needed, and member function implementations. However, before individual
classes
are designed and implemented, they are first recognized as part of some
larger software
system.
This section introduces an object-oriented design (OOD) methodology in the
context of a real-world problem—the cashless jukebox. The strategy is
based on the
responsibility-driven design methodology of Wirfs-Brock, Wilkerson, and
Wiener
[Wirfs-Brock 90].
Another major component of object-oriented software development is the
Component/
Responsibility/Collaborator (CRC) card introduced by Kent Beck and Ward
Cunningham [Beck/Cunningham 89]. This simple and effective tool consists
of a set
of 3-by-5-inch index cards. CRC cards were first used to help people
understand
object technology. Developers employ them to develop large-scale, object-
oriented
systems. Because the word collaborator has caused confusion, CRC cards
will henceforth
be referred to as Component/Responsibility/Helper (CRH) cards.
The first step in object-oriented analysis involves identification of the key
abstractions—
the major classes. The system is modeled as a set of classes, each with
its own responsibilities. You will see how team members “become” an
object through
role playing. Playing the roles of the objects helps the team identify the
responsibilities
of each while determining the relationships between them. Role playing
helps
the team understand the problem, model a solution, and iron out the rough
spots
early in development, when it is relatively cheap and easy to do so.

object model

has two related but distinct meanings:

1. The properties of objects in general in a specific computer programming

language, technology, notation or methodology that uses them. For example, the
Java objects model, the COM object model, or the object model of OMT. Such
object models are usually defined using concepts such as class, message,
inheritance, polymorphism, and encapsulation. There is an extensive literature on
formalized object models as a subset of the formal semantics of programming
languages.
2. A collection of objects or classes which a program can examine and manipulate
some specific parts of its world. In other words, the object-oriented interface some
service or system. Such an interface is said to be the object model of the
represented service or system. For example, the Document Object Model (DOM)
[1] is a collection of objects that represent a page in a web browser, used by script
programs to examine and dynamically change the page. There is a Microsoft
Excel object model [2] for controlling Microsoft Excel from another program, and
the ASCOM Telescope Driver [3] is an object model for controlling an
astronomical telescope.

The elements of the object model are,

Information hiding: It is the principle of concealing the internal data and procedures of
an object and providing an interface to each object in such a way to reveal as little as
possible about its inner workings.
Encapsulation: The user cannot see the inside of the object “capsule” but can use the
object by calling the object’s methods.
Example – A car is engine.
Data abstraction: Data are abstracted when they are shielded by a full set of method and
only those methods can access the data portion of an object.
Class hierarchy: Different properties and behaviors are used as the basis for making
distributions between classes and substances. At top of the class hierarchy are the most
general classes and at the bottom are the most specific.
Inheritance: It is the property of an object oriented systems that allows objects to be
built from other objects. It is the relationship between classes where one class is the
parent class of another class.
Dynamic inheritance – It allows objects to change and evolve overtime.
Multiple inheritance – OOS permits a class to inherit its state and behaviors
from more than one super class.
Polymorphism: It means that the same operation may behave differently on different
classes. It is also the relationship of objects of many different classes by some common
super class. These are all the elements of the object Model.