Introduction into Object Orientation - OOPs

Introduction into Object Orientation

(klick here to get the German version)

Contents
1 Introduction
1.1 Purpose
2 The Object-Orientation Concept
2.1 Observation
2.2 Focus
2.3 Basic Terminology
2.3.1 Classes
2.3.2 Objects / Instances
2.3.3 Attributes
2.3.4 Methods
2.3.5 Construktor
2.3.6 Object Identity and Reference Semantics
2.3.7 Visibility
2.3.8 Events
2.4 Inheritance
2.4.1 Polymorphism
2.4.2 Generalization and Spezialization
2.5 Interfaces
3 Softwareengineering – the OO Development Process
3.1 OO Engineering aspects
3.1.1 Responsibilities
3.1.2 UML - The modeling Language
3.1.3 Architecture
3.2 The iterative Development Process
3.3 Analysis
3.4 Design
3.4.1 Design Patterns
3.5 Implementation
3.5.1 Client-Server
3.5.2 Responsibilities
4 Advantages and Disadvantages
4.1 Quality
4.1.1 Abstraction and Encapsulation
4.1.2 Inheritance and Polymorphism
4.1.3 Reusability

Page 1 of 36
Introduction into Object Orientation - OOPs

4.1.4 Componentware
4.1.5 Interfaces
5 Conclusion
6 Reading List
6.1 Literaturverzeichnis

1 Introduction
1.1 Purpose

The purpose of this introduction to Object-orientation is to provide

interested readers with a brief overview of this new software
development technique. The introduction does not provide a deep
understanding of object-orientation and so should not be used as a
replacement for a training course or for more detailed reading. ABAP/4
programming knowledge will help you to understand this introduction.
ABAP/4 programming knowledge will help you to understand this
introduction.The programming language ABAP/4 was renamed ABAP
Objects after the introduction of object orientation.
Many thanks to the following people, whose criticisms helped me to
write this document: Peter Dell, Andreas Flach, Petra Friedmann,
Susanne Jung, Holger Meinert, Dietmar Nowotny, Claus von Riegen,
Stefan Roßmanith, Oliver Stabel, Daniel Stephan, Katharina Wehrheim
and Oliver Wiegert.

2 The Object-Orientation Concept

2.1 Observation

This introduction is strongly oriented towards the ABAP Objects

programming language. Note that many of the object-oriented
concepts described here are independent on the implementation
language.

2.2 Focus

Bertrand Meyer – a godfather (if not the godfather) of object

technology - answers the question, "what is object-orientation", with
the following sentence:
Object-orientation is a software engineering technique.
Bertrand Meyer: Object Success – A Manager's Guide to Object
Orientation, Prentice Hall 1995
What Niklaus Wirth is for structured programming, Bertrand Meyer is

Page 2 of 36
Introduction into Object Orientation - OOPs

for object orientation. Bertrand Meyer developed the object-oriented

programming language Eiffel and wrote the book "Object-oriented
software construction" (ISBN 3-446-15773-5). This book - some people
call it "the Bible of object-oriented programming" - founded his
reputation as the godfather of object-orientation.
This view may be highly abstract, but from the management point of
view it sets the focus correctly. The introduction of object-orientation
into the software development process involves more than simply
using an object orientated programming language such as Java, C++,
Eiffel, Smalltalk or even ABAP Objects.
Before I examine this point in more detail in Chapter Software
Engineering, I will define some fundamental object-orientation
terminology in the following sections.
As is the case for every new technology, object-orientation has
produced new terminology. On the one hand this was because there
were no adequate concepts, on the other hand existing concepts have
simply been given new names.

2.3 Basic Terminology

For a long time it was standard practice in software development to

subdivide software systems according to the system's functions.
Object-orientation takes another approach. Instead of concentrating on
functions, the object-oriented approach concentrates on data
abstractions – so-called Classes.

2.3.1 Classes

Classes are the central element of object-orientation.

A Class describes a general element or a general concept, for example the abstract
concepts Business Partner, Material, Transaction, Equipment or List. Classes realize an
abstract data type.
Classes contain components: Attributes, Methods and Events. These
components are described later in this document.

In ABAP Objects classes are made up of a definition and an implementation part.

CLASS cl_party DEFINITION. "party = Business Partner

ENDCLASS.
CLASS cl_party IMPLEMENTATION.
ENDCLASS.

This information is probably not of much immediate help. Please bear

with me, the next section should help to clarify things.

Page 3 of 36
Introduction into Object Orientation - OOPs

2.3.2 Objects / Instances

An object is nothing more than an instance of a Class. For example, the

business partner Meyer is an instance of the Class Business Partner,
the business partner Miller is another instance. All of the instances of
the business Class Business Partner have something in common: they
operate in a particular program context such as Business Partner.
Scott W. Ambler (The Object Primer – The Application Developer’s Guide to Objet-
Orientation, ISBN: 0-13-242496-7) describes objects as follows

Object – A person, place, thing, concept, or event that is applicable to the system at hand.
Objects both know things (i.e., they have data) and they do things (i.e. they have
functionality).

In ABAP Objects, objects are created with the command CREATE OBJECT. The
developer receives an object reference as a result of its creation:

CLASS cl_party DEFINITION.

ENDCLASS.
CLASS cl_party IMPLEMENTATION.
ENDCLASS.
DATA: instance TYPE REF TO cl_party.

START-OF-SELECTION "This event must be explicitly entered by class definitions".

CREATE OBJECT instance.

Classes are more or less the blueprint, objects are the realization of
the blueprint. Classes define the structure and behavior of all objects,
which belong to them.
Observation
Before I present the individual components of a Class, I will briefly
mention some common areas of confusion:
 confusion between software objects and real-world objects

and
 confusion between objects and Classes

Software objects are data structures in a computer and therefore are

not real objects. An instance (which is equivalent to an object) of the
Class Business Partner is not Mr. Miller himself, but rather an abstract
and limited structure at a processing point in a program.
Confusion between Class and Object is even more common. This is
often caused by poor communication between people. Many people
talk or write about objects when really they mean Classes. This is
probably because the new paradigm is called Object-orientation and
not Class-orientation. If for example, the reuse of objects is being

Page 4 of 36
Introduction into Object Orientation - OOPs

discussed, what is actually meant is the reuse of Classes. Unfortunately

this often comes up in the literature. This makes the texts
unnecessarily hard to understand.
This inaccuracy is unfortunately also present in the BOR (Business
Object Repository). It should actually be called the BCR (Business Class
Repository).
I know from my own experience, that particularly in training courses,
the teachers must be very careful to use the correct terminology,
otherwise the confusion caused to the listeners quickly leads to
frustration.

2.3.3 Attributes

In one of the above sections I mentioned the objects Meyer and Miller,
which are both instances of the Class Business Partner. You may have
asked yourself the question: How does an object know, that it
represents the person Meyer or Miller?
This is the role of Attributes. Attributes can take on values within an
object at runtime. The sum of all attributes and their values describes
the state of an object.

In ABAP Objects attributes are defined in the definition part via the ABAP keyword
DATA. In this example we have defined that the name of a business partner may be 50
characters long and is of the data type Character:
CLASS cl_party DEFINITION.
PUBLIC SECTION.
"I will return later to the meaning of the language element Public Section see Visibility

DATA: name(50) type C.

ENDCLASS.

Attributes can be defined as instance dependent as well as Class

dependent. Class attributes (Class attributes are also called static
attributes.)are not tied to a single instance, rather they "belong" to all
instances of the Class. These attributes exist only once in main
memory. Instance-dependent attributes exist once per instance and are
tied to a single instance. For example, the attribute name is an
instance-dependent attribute, while the attribute instance_count
could be a Class-dependent attribute, in which the number of instances
of the Class cl_party could be noted.

In ABAP Objects you differentiate between instance-dependent and class-dependent

attributes by means of the ABAP keywords DATA or CLASS-DATA to be used in the
definition part:

CLASS cl_party DEFINITION.

Page 5 of 36
Introduction into Object Orientation - OOPs

PUBLIC SECTION.
CLASS-DATA: instance_count type i.
DATA: name(50) type c.
ENDCLASS.

START-OF-SELECTION.
DATA: instance TYPE REF TO cl_party.
* Access to the different attribute types is also defined in the syntax:
* Class attribute: cl_class=>instance_count
* Instance attribute: instance->name

IF cl_class=>instance_count < 50.

CREATE OBJECT instance.
...
ENDIF.
IF instance->name <> 'Miller'.
...
ENDIF.

Attributes therefore describe the structure (type) of the Class and all of
the objects belonging to the Class. Note that the attribute values do
not guarantee the uniqueness of objects. During a program run many
objects with the name Miller could be created. These objects would all
have - as in real-life - a separate identity and are different business
partners who happen to have the same name.

2.3.4 Methods

As well as attributes, Classes have so-called Methods (you could say

functions instead of methods but, as mentioned in the introduction:
New technologies require new names). While attributes describe the
static structure of a class and its objects, Methods describe the
behavior of objects within a class. With the help of methods, the
system provides operations, services and functions. Via methods, a
user can manipulate the objects in a class or also the class itself. As for
attributes, there are instance-dependent as well as class-dependent
(static) methods.
In order to carry out instance-dependent (or instance-dependent)
methods, the calling program needs a specific instance of the class.
That is, the calling program must have a defined reference variable,
that points to a specific instance. Class methods are not instance-
dependent. They can be called at any time by a user. To see how the
syntax calls the various method types, see the following example.

ABAP Objects differentiate between instance-dependent and class-dependent methods via the

Page 6 of 36
Introduction into Object Orientation - OOPs

ABAP keywords METHODS or CLASS-METHODS used in the definition part:

TYPES: Boolean(1) TYPE c,

PName(50) TYPE c.

CLASS cl_party DEFINITION.

PUBLIC SECTION.
CLASS-DATA: instance_count TYPE i.
DATA: name TYPE PName.

CLASS-METHODS: is_class_with_objects RETURNING VALUE(re_bool) TYPE

Boolean.
METHODS: change_name IMPORTING VALUE(im_new_name) TYPE PName.
ENDCLASS.

CLASS cl_party IMPLEMENTATION.

METHOD is_class_with_objects.
IF instance_count > 0.
re_bool = co_true.
ELSE.
re_bool = co_false.
ENDIF.
ENDMETHOD.
METHOD change_name.
name = im_new_name.
ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.
DATA: instance TYPE REF TO cl_party.
DATA: bool TYPE Boolean.

* * The syntax defines how to call the different method types:

* Class method: cl_class=>is_class_with_objects
* Instance method: instance->change_name

CALL METHOD cl_party=>is_class_with_objects RECEIVING re_bool = bool.

IF bool = co_false.
CREATE OBJECT instance.
CALL METHOD instance->Change_name EXPORTING im_new_name = 'Miller'.
ENDIF.

2.3.5 Construktor

Page 7 of 36
Introduction into Object Orientation - OOPs

Objects must be created at runtime (CREATE OBJECT – instruction in

ABAP Objects). With their creation they also get their own identity.
However, there are no fixed attribute values linked to the identity. You
are probably already wondering how objects get to their initial state.
How do objects recognize their initial attribute values? How does an
object know during its creation that it is a Miller and not a Meyer?
The Constructor concept exists specifically to answer this question.
The constructor is a method which runs automatically during the
creation of an object. The constructor allows you to define IMPORTING-
parameters.

In ABAP Objects you differentiate between instance-dependent and class-dependent

constructors via the language elements METHODSand CLASS-METHODS to be used in
the definition part and via their names constructor and class_constructor:

Types: PName(50) type c.

CLASS cl_party DEFINITION.

PUBLIC SECTION.
* The class constructor has no parameters
CLASS-METHODS: class_constructor.
METHODS: constructor IMPORTING value(im_name) TYPE PName.
DATA: name TYPE PName.
ENDCLASS.

CLASS cl_party IMPLEMENTATION.

METHOD class_constructor.
...
ENDMETHOD
METHOD constructor.
name = im_name.
ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.
DATA: instance TYPE REF TO cl_party.
* At this point the class constructor and the instance constructor are executed
CREATE OBJECT instance EXPORTING im_name = 'Miller'.

The class constructor is called by the first access to a class element

(method, attribute, event, object), the (instance) constructor by the
creation of an object (CREATE OBJECT).
You can now create small programs with the help of the ABAP Objects
language instructions you have learned. You know the basic elements
of classes (attributes and methods), the differences between classes
and their objects and how to express these in ABAP Objects.

Page 8 of 36
Introduction into Object Orientation - OOPs

Now it is time for you to just have a go at implementing a small class.

Write a report for it as a local, private object and just copy the above
example, or the previous one (Make sure that the R/3 System is release
4.5A or above.).

2.3.6 Object identity and reference semantics

With the help of the previous examples, you have established that
objects belonging to a class are not created by the simple definition of
the class. Neither does the instruction DATA: instance ref to
cl_party.create an object. This instruction only creates a Reference,
which in its initial state has the logical value INITIAL . Only with the
instruction CREATE OBJECT instance is the memory area for a new
object requested from the system. The reference instance then refers
to the object which has just been created. (The command CLEAR
instance. at this point means that the object, to which the reference
variable refers, cannot be referenced. Therefore it can no longer be
addressed in this progam run. A Garbage Collector running in the
background ensures that the object is removed from memory.
This separates object-oriented implementation from classic
implementation. With the classic DATA instruction, main memory is
reserved (which might never be used) and is preallocated the initial
state of the relevant variable. With the "object-oriented" instruction
DATA-x-TYPE-REF-TO, only the intention to create an object is
expressed. The only storage space occupied is for an object reference.
In addition, every object has its own identity. Two references, which
refer to objects, are only identical if they refer to the same object.
Similarity between the attribute values of these objects is not the
deciding factor.
I want to explain in more detail the terms object identity and reference
semantics using the following example.

TYPES: PName(50) TYPE c.

CLASS cl_party DEFINITION.

PUBLIC SECTION.
Methods: constructor IMPORTING value(im_name) type PName.

DATA: name type PName.

ENDCLASS.

CLASS cl_party IMPLEMENTATION.

METHOD constructor.
name = im_name.
ENDMETHOD.

Page 9 of 36
Introduction into Object Orientation - OOPs

ENDCLASS.

DATA: instance TYPE REF TO cl_party.

DATA: instance2 TYPE REF TO cl_party.
DATA: instance3 TYPE REF TO cl_party.

START-OF-SELECTION.
CREATE OBJECT instance EXPORTING im_name = 'Miller'.
CREATE OBJECT instance2 EXPORTING im_name = 'Miller'.

* Reference semantics !!!

IF instance = instance2.
* This is not the case, as instance refers to a different object than
instance2.
ENDIF.

* Attribute values are the same !!!

IF instance->name = instance2->name.
* This is the case
ENDIF.

Instance3 = instance.
IF instance3 = instance.
* Both references refer to the same object and are therefore
identical.
ENDIF.

The first IF-Query (IF instance = instance2.)via the object reference

produces the value false, although both objects have the same
attribute value "Miller". Note that in object-oriented languages the
reference semantics apply for classes and their objects. Both objects
have the attribute value Name = Miller, but they are independent
objects with their own identity. The references therefore refer to two
different objects, although their attribute values are completely
identical.
If you want to compare two objects belonging to a class with one
another, then you must write an individual method (for example, a
class method is_equal). Then you can compare the objects within this
method.

2.3.7 Visibility

An important feature of object-orientation is the encapsulation of

attributes and methods - ultimately of functionality - in classes. A class

Page 10 of 36
Introduction into Object Orientation - OOPs

guarantees its user specific properties and specific behavior. The sum
of these properties is called the class interface. The Visibility
mechanism defines the class interface which is available to the users.
There are three commonly defined types of visibility in object-oriented
technology:
 Public
The relevant class component (attribute, method, event) is visible to all classes.
 Protected
The relevant class component (attribute, method, event) is visible to the class
itself and all inheritors. We will return to the terms Inheritor and Inheritance later in this
document (see Inheritance). What is important here is the difference between Public and
Private.
 Private
The relevant class component (attribute, method, event) is only visible to the class
itself.

You may be saying to yourself: "Now I know what is meant by the term PUBLIC
SECTION." All class components defined in the PUBLIC SECTION are callable by
their user, all others are not (with the exception of the PROTECTED SECTION). You can
use this construct to implement Information Hiding.

In this example the attribute name is hidden from the users. Access to the information it
contains is realized via the method get_name.

TYPES: PName(50) type c.

CLASS cl_party DEFINITION.

TYPES: ty_name(75) TYPE c.
PUBLIC SECTION.
METHODS: get_name EXPORTING ex_name TYPE PName,
constructor IMPORTING VALUE(im_name) TYPE PName.
PRIVATE SECTION.
DATA: name TYPE ty_name.
ENDCLASS.

CLASS cl_party DEFINITION.

METHOD constructor.
name = im_name.
ENDMETHOD.
METHOD get_name.
ex_name = name.
ENDMETHOD.
ENDCLASS.

DATA: instance TYPE REF TO cl_party.

Page 11 of 36
Introduction into Object Orientation - OOPs

DATA: name TYPE PName.

START-OF-SELECTION.
CREATE OBJECT instance EXPORTING im_name = 'Miller'.
CALL METHOD instance->get_name IMPORTING ex_name = name.

Observation
In this example I will demonstrate that with the help of visibility and
the consequent definition of an independent interface, the individual
(private) implementation of a class can be separated from its users.
While the user knows the format of the business partner name as a
global type PName (50 character text field), the class itself implements
the name as a 75 character text field.

2.3.8 Events

Events are recognized in particular by programming interfaces of the

GUIs (Windows, Motif, etc.), for example, you can "ask" the GUI to
trigger an event if the user moves the mouse over a specific part of the
screen. When the event occurs you are telling the GUI to change the
shape of the mouse pointer.
Events allow for the loose coupling of components (classes or objects)
in a system. The event trigger does not normally know at the time of
coding who is going to react to the event. Those components, which
want to react to the event, register at the event runtime, in that they
tell the runtime environment which method is to be executed when the
event is raised. In this way many components can register for an
event.
Event handler methods can proceed synchronously as well as
asynchronously. At present, ABAP Objects only supports synchronous
calling of the event handler method.

Instances of the Class cl_class create an event object_created. The class method
process_event belonging to the class cl_class1 processes this event.

CLASS cl_class DEFINITION.

PUBLIC SECTION.
EVENTS: object_created EXPORTING value(ex_reference) TYPE REF TO cl_class.
METHDOS: CONSTRUCTOR.
ENDCLASS.

CLASS cl_class IMPLEMENTATION.

METHOD CONSTRUCTOR.
RAISE EVENT object_created EXPORTING ex_reference = me. "me references the
current instance

Page 12 of 36
Introduction into Object Orientation - OOPs

ENDMETHOD.
ENDCLASS.

CLASS cl_class1 DEFINITION.

PUBLIC SECTION.
CLASS-METHODS: initialize.
PRIVATE SECTION.
CLASS-METHODS: process_event FOR EVENT object_created OF cl_class.
ENDCLASS.

CLASS cl_class1 IMPLEMENTATION.

METHOD initialize.
SET HANDLER process_event FOR ALL INSTANCES.
ENDMETHOD.
METHOD process_event.
DATA: reference TYPE REF TO cl_class1.
CREATE OBJECT reference.
ENDMETHOD.
ENDCLASS.

DATA: instance TYPE REF TO cl_class.

START-OF-SELECTION.
CALL METHOD cl_class1=>initialize.
CREATE OBJECT instance.

With the help of the class method initialize the class cl_class1
registers the method process_event at the event object_created for
all instances of the class cl_class. When an object is created for the
class cl_class (CREATE OBJECT instance.), the event
object_created is raised in the constructor. The consequence is that
the method process_event belonging to the class cl_class1 is
executed.

2.4 Inheritance

The concept of inheritance is a new functionality which is made

possible by object-oriented software development. Similar mechanisms
do not yet exist in classical programming languages. So what
difference does inheritance make?
Firstly, I want to give you a definition of inheritance:

Inheritance defines the relationship between classes, in which a class (subclass) uses the
structure and behavior that has already been defined in one or more other classes
(superclasses).

Page 13 of 36
Introduction into Object Orientation - OOPs

So you might be thinking "Inheritance is about reuse!" Correct!

However, it is not quite so simple.
Allow me to use a concrete example to explain inheritance:
Collection. Expressed in the abstract, a collection is any number of
objects (more precisely object references).
However, if you want to work with a concrete collection of objects, ask
yourself the following questions: "What does the collection contain?
Are there twin references to one object? Are the objects sorted
according to any particular format?"
You will quickly come to the conclusion that a single type of collection
is not sufficient. Collections are required that guarantee:
 that no double entries are present (Sets)
 that a specific order is adhered to (Sequence)
 that the objects are sorted according to their keys (KeySortedCollection)
 etc.

You may be thinking: "So I have many types of collection. This is therefore a good
opportunity to implement my new knowledge. I will implement each type of collection as
a class!" In principle this approach is correct. However, you will soon establish that all
collections have several components in common:
 Each class requires a method in order to add objects to a collection
 Each class requires a method in order to delete objects from a collection
 Each class has a method which identifies the number of object references in the
collection
 ... You can probably think of some other similarities

Inheritance is the solution to this situation. You implement all of the similarities in the
class Collection. You then implement the individual types of collection in their own
classes which are Subclasses of the class Collection. As a subclass, these classes
inherit all of the components of the Superclass. Attributes, methods and events are
inherited. In addition, you can implement additional attributes, methods and events in the
subclass. If a method from the Public Section or Protected Section of the
superclass cannot be used in this way, then the method can be redefined in the subclass.
You can find further information in the following sections: Polymorphism und
Generalization and Specialization.

Page 14 of 36
Introduction into Object Orientation - OOPs

Inheritance tree for Collections

In the following example I have partially implemented the class
cl_collection and its inheritor class cl_set. The method addbelonging
to the class cl_collection is redefined by the method addbelonging to
the class cl_set.

TYPES: BEGIN OF ty_item,

item TYPE REF TO OBJECT,
END OF ty_item.
TYPES: ty_items TYPE ty_item OCCURS 0.

CLASS cl_collection DEFINITION.

PUBLIC SECTION.
METHODS add IMPORTING im_item TYPE ty_item.
PROTECTED SECTION.
DATA items TYPE ty_items.
ENDCLASS.
CLASS cl_collection IMPLEMENTATION.
METHOD add.
APPEND im_item TO items
ENDMETHOD.
ENDCLASS.

CLASS cl_set DEFINITION INHERITING FROM cl_collection.

PUBLIC SECTION.
METHODS add REDEFINITION.
ENDCLASS.
CLASS cl_set IMPLEMENTATION.
METHOD add.
* No double entries are allowed in Sets
READ TABLE items WITH KEY item = im_item-item TRANSPORTING NO
FIELDS.
IF sy-subrc <> 0.
CALL METHOD SUPER->add EXPORTING im_item = im_item.
ENDIF.
ENDMETHOD.

Page 15 of 36
Introduction into Object Orientation - OOPs

ENDCLASS.

In the method add belonging to the cl_set the method add belonging
to the superclass cl_collection is called via CALL METHOD SUPER-
>add.
Observation
In order to avoid a class becoming a superclass, FINAL is added. This
addition says that no subclass may be defined for the relevant class. In
order to avoid the situation where a class carries instances, there is the
addition ABSTRACT. Classes which carry this addition, should generally
serve as a superclass and contain a default implementation. This
approach is particularly meaningful in frameworks.

2.4.1 Polymorphism

Polymorphism occurs, where classes implement the same functionality

with different methods (one functionality, several methods but the
same name). This can occur via an inheritance relationship, in that the
methods belonging to the superclass are redefined in the subclasses
and implemented differently. ABAP Objects requires the method names
to be the same and the signature to be the same (signature = method
interface).
Polymorphism can be achieved in 2 ways:
 Two independent classes implement methods with the same names and the same
signature with the intention, that the methods should be called dynamically from a
third location.
 A superclass implements a method, and in a subclass you want to reimplement the
same method, as the superclass implementation is not suitable for the subclass.

The first scenario will not occur very often in ABAP Objects, as the interface concept
was created precisely for such cases (see Interfaces).

2.4.2 Generalization and Spezialization

In the above section on inheritance, I have tried to explain inheritance

in terms of technical software problems and their solutions (in the
Collections example). However, inheritance is not just a theoretical
software creation. Its roots lie in the human character trait, which not
only classifies objects but also tends to fit them into a hierarchy.
Consider an example from biology. We separate life forms into animals
and plants. The animals then divide into single-celled and many-celled,
and so on.
The characteristics which are assigned to living organisms in general,
also apply for all plants and animals. Specific criteria are then applied
to differentiate plants from animals. Therefore there are characteristics

Page 16 of 36
Introduction into Object Orientation - OOPs

that all animals have in common, but not all plants. On the other hand,
there are characteristics that all plants have in common, which do not
apply for all animals.
This principle of hierarchical classification, which lies at the heart of
human thought, is represented in object-oriented development by the
inheritance concept. Classes are therefore subdivided into subclasses.
These subclasses are defined as a Specialization of the superclass.
Superclasses are then defined as a generalization of the subclass.

2.5 Interfaces

The Interface concept describes a class interface. You can define the
same components in an interface that you can in classes, however
without implementing them.
Classes can implement interfaces, and subsequently be addressed via
these interfaces. For example, a class cl_class can implement the
interface if_archive and thereby become archivable, or it can
implement if_workflow and thereby take part in a workflow. This
opens an additional mechanism of polymorphism, however without
being dependent on inheritance.This combination of classes with simple
inheritance and interfaces is more highly regarded by many experts than full multiple
inheritance. Example: Java.
In addition to object references (DATA: instance TYPE REF TO
cl_class) there are also Interface References (DATA: reference TYPE
REF TO cl_interface). A class which implements a specific interface
can be addressed via this interface reference. Using such an interface
reference, you can access the components defined in the interface. In
this way a user can view different classes through the 'spectacles' of
an interface and address them in a uniform manner.
Interfaces therefore define specific, generic functionality. In contrast to
classes, interfaces generally have not only many users, but also
many implementers.

The Interface if_interface is implemented via the classes cl_class und cl_class1.

INTERFACE if_interface.
METHODS: a_method.
ENDINTERFACE.

CLASS cl_class DEFINITION.

PUBLIC SECTION.
INTERFACES: if_interface.
ENDCLASS.
CLASS cl_class IMPLEMENTATION.
METHOD if_interface~a_method.

Page 17 of 36
Introduction into Object Orientation - OOPs

...
ENDMETHOD.
ENDCLASS.

CLASS cl_class1 DEFINITION.

PUBLIC SECTION.
INTERFACES: if_interface.
ENDCLASS.
CLASS cl_class1 IMPLEMENTATION.
METHOD if_interface~a_method.
...
ENDMETHOD.
ENDCLASS.

* Definition of class references and interface references

DATA: instance TYPE REF TO cl_class.
DATA: instance1 TYPE REF TO cl_class1.
DATA: ifref TYPE REF TO if_interface.

START-OF-SELECTION.
CREATE OBJECT instance.
ifref = instance. "This assignation is described as cast
CALL METHOD ifref->a_method.

CREATE OBJECT instance1.

ifref = instance1. „Cast
CALL METHOD ifref->a_method.

3 Software Engineering - the OO

Development Process
The confusion mentioned in Objects / Instances (objects versus classes,
software objects versus real objects) is also due to additional reasons
than those mentioned there. Object-orientation allows you for the first
time to implement a uniform - i.e. implemented using uniform methods
- software construction process. Analysis, design and implementation
are based on the same technology or methodology. At the same time,
the developer is put in a position where he/she is able to model the
external system - e.g. financial accounting or customer administration -
using an adequate software concept.
This model closes the gap between problem and solution. Bertrand Meyer
talks about the impedance problem of classic engineering techniques. Users and
developers talk about the same elements (business partner, material).

Page 18 of 36
Introduction into Object Orientation - OOPs

Analysis, design and implementation are "talking the same language".

Method inconsistency is not apparent and not at all inherent in the
process.

3.1 OO Engineering Aspects

Before I describe the individual phases of the development process in

more detail, I want to describe several fundamental aspects of OO
engineering.

3.1.1 Responsibilities

Object-oriented thinking has a lot to do with responsibility.

Which object is responsible?

This should be the central question for every developer. For each
functionality that is required, you should clarify in which area of
responsibility of a class/object the required functionality lies. This class
should then also offer a relevant service (method, event etc). If the
responsibility lies outwith your own area, then corresponding
communication is required. The individual developers may have to talk
with each other, in order to decide how the functional responsibility
should be allocated.

3.1.2 UML - The Modeling Language

Page 19 of 36
Introduction into Object Orientation - OOPs

Graphic: the history of UML

The modeling language UML (Unified Modeling Language) was chosen
as the standard by the OMG (Object Management Group, see also
section Componentware) in 1997. It allows for the standard
representation of the different aspects of an object-oriented software
model. Therefore it shows aspects of componentization, packaging,
relationships and more.
The following types of diagrams are standardized in UML:
 Use Case Diagram
This diagram describes Use Cases (also known as scenarios) and the relevant
actors that participate in these use cases.
 Class Diagram
The central diagram for representing static structure of classes, interfaces and
packages.
 Sequence Diagram
Diagram representing message sequences (messages are the basic means of
communication between objects. In the implementation, messages are usually
realized by method calls.)
 State Diagram
State diagram for classes.

Page 20 of 36
Introduction into Object Orientation - OOPs

 Activity Diagram
Diagram to represent system behavior (particularly suitable for workflow and
parallel processes).
 Collaboration Diagram
Diagram of static and dynamic representation of communications relationships
between classes or objects.
 Object Diagram
This diagram models relationships between objects, which are not directly visible
in the class diagram
 Component Diagram
Diagram representing development components and their dependencies
 Deployment Diagram
Diagram representing hardware and software dependencies

I can only briefly explain the UML in this section. The next picture
shows a class diagram. If you want more information on the UML, we
recommend the book: "UML Distilled – Applying the Standard Object
Modeling Language" by Martin Fowler.

Graphic: Example of a UML class diagram

3.1.3 Architecture

The architecture of an object-oriented software system is of crucial

significance. The different classes must be constructed according to
the same architectural rules. At this stage I should really define what is meant
by architecture. However, from the point of view of this paper a rough idea is
sufficient. Architecture could include the transaction concept, the database concept,

Page 21 of 36
Introduction into Object Orientation - OOPs

If this is not
the concept for representing objects, error handling and much more.
the case, then it is harder to get classes to communicate with one
another. It is particularly difficult to integrate different classes into a
functioning software package.
In classic programs, data is passed from interface to interface. Where a
program has to use two non-matching interfaces, a conversion routine
can easily be inserted and you can carry on.
This is no longer possible in object-oriented systems. The calling class
no longer has the authority to transfer data between two interfaces. It
only has references to objects, whose data it does not know. Data
conversion by the calling class is no longer possible.
Bertrand Meyer considers the term "architecture" to be so important in
the object-oriented environment, that he places the Architecture
Principle first in his list of the ten fundamental concepts of object
technology:

Object technology mainly influences the architecture of software systems.

As well as this uniform architecture, is it just as important that the

classes belonging to a class library are tailored according to the same
criteria, such as granularity, separation into main- and helper classes,
equivalent inheritance trees etc. A conceptionally inconsistent class
library has the same negative effects as classes that are created
according to different architectural principles. It is difficult for classes
at different levels of abstraction to communicate with one another.
Imagine a real-life example. A bricklayer and an architect have
completely different views of a house. While the bricklayer knows
every stone of the wall he has built, the architect is only interested in
the result, that is the wall must be built according to plan. If the
architect had to concern himself with every single stone or every single
roofing tile of a house, then the house plans would take far too long to
produce.

3.2 The iterative development process

The procedure for an object-oriented development process is iterative.

This iterative procedure implies that the various phases of a
development process (analysis, design, implementation) occur several
times, in so-called Increments.
A typical procedure model for a project is:
 Divide the project into several parts.
 Evaluate the relative importance of these parts.
 Start the project with the most important part and carry out the analysis, design
and implementation phases.

Page 22 of 36
Introduction into Object Orientation - OOPs

 After validation (e.g. after the first increment, you can see that the project aim is
achievable), the next increment can be carried out for the next most important
project part.

3.3 Analysis

Scott W. Ambler (http://www.ambysoft.com/ooModelingProcess.pdf)

describes the analysis phase as follows:

Detailed analysis focuses on what to be built, not how.

The analysis phase of object-oriented software development has hardly

changed from the classic development process. The main tools for the
analysis phase are the now standardized - but previously familiar - UML
Use Case Diagrams (see UML - Die Modeling Language) and the so-
called CRC-Cards (Class Responsibility Collaborator Cards). You can use
the CRC cards in the analysis phase to try to identify the classes.
Depending on how far the analysis phase has progressed, the following
results may be available:
 Package diagramm
 Conceptional class diagram
 Conceptional sequence diagram

3.4 Design

In the book by Erich Gamma et al. (Erich Gamma, Richard Helm, Ralph
Johnson, John Vlissides: Design Patterns - Elements of Reusable Object-oriented
Software, Addison-Wesley, ISBN: 0-201-63361-2), the authors write:

Designing object-oriented Software is hard, and designing reusable object-oriented

software is even harder.

... and that is also my opinion. But don't worry, the design has not
necessarily become more difficult. For classically designed software,
many modeling aspects are first decided in the implementation phase,
without the participants noticing. Therefore many problems are simply
not visible at the design phase.
The sentence: "We'll make the decision at implementation when we
know this or that" is often heard during the modeling phase, when
decisions are being avoided.
However, these (postponed) decisions must, for the object-oriented
procedure model, be decided during the modeling phase. An
incomplete class model has a significantly greater negative effect on
the implementation. Where there is an obvious gap in the design, an
implementer cannot quickly "program something in", but must first
interrupt his or her work and consider what needs to be done.

Page 23 of 36
Introduction into Object Orientation - OOPs

Responsibilities - whether organizational (which developer needs to

contribute to the solution) or implementation-specific (which class is
responsible for the additional required functionality) - must be clarified
and a new round of modeling must be carried out.
Naturally the iterative development process supports the modeling of
"gaps" in the design. These "gaps" can then be filled in the second
iteration. However, the gaps themselves must be the subject of
modeling.
In this context, it is naturally very important to have tools available
during the modeling phase, which should make the modeler's task
easier. Luckily for us Gamma and his colleagues have done the pioneer
work and brought the concept of Design Patterns into the discussion.

3.4.1 Design Patterns

Design patterns were introduced by an architect (!), Christopher

Alexander. He described recurring problems in building construction
and their recurring solutions:

Each pattern describes a problem which occurs over and over again in our environment,
and then describes the core of the solution to that problem, in such a way you can use this
solution a million times over, without ever doing it the same way twice.
Christoper Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-king, Shlomo
Angel: A Pattern Language, Oxford University Press, New York, 1977

Design patterns describe solutions which have actually been

implemented. Design patterns are not created at a desk, in order to
then reside in technical literature. On the contrary: in order to
recognize design patterns you need to look at many, many solutions,
recognize a common pattern, abstract this pattern and then simply
write up the Design Pattern.
Design patterns are discovered and not developed.
Design patterns have - as well as reusability - a further positive
characteristic: With the help of a term (name of a design pattern),
complex content can very quickly be named and communicated
(assuming that all recipients of the communication are familiar with
design patterns).
For further information on this topic, see the book by Gamma et al.

3.5 Implementation

In this section I will name several principles, according to which object-

oriented program systems are implemented. The naming of principles
is not intended to be complete and is only intended to give a brief
insight into object-oriented implementation.

Page 24 of 36
Introduction into Object Orientation - OOPs

3.5.1 Client-Server

Different classes behave with one another like a client-server system.

As the developer of a class, I should always be thinking of the users of
this class. From their point of view I play the role of the server.
However, as soon as I call methods from other classes I become the
client. I call a method and expect a result. It doesn't matter to me how
this result is reached. The main thing is that the method delivers what
is requested. The implementation details of the foreign class should
only interest me in exceptional cases.
In principle, as a client I should only cooperate with the public
interfaces of the other classes. As a server, I should only publish those
components (attributes, methods, events), whose existence I want to
make known and which may be of use to a potential user.

3.5.2 Responsibilities

The principle of responsibility named in Responsibilities is also valid for

the implementation:

Which object is responsible

This should also be the central question here for every developer.

Exactly one developer is responsible for every class.

This responsibility should be self-evident. In classically developed

software systems, you often find responsibility sharing. This is not
desirable in object-oriented software systems.This statement also
indirectly defines the maximum size of a class. It must not be - with
regard to the coding as well as the functionality - so big that an
individual developer can no longer maintain it.

The client is responsible for the correct use of the server.

If a class uses services from another class, then this client is naturally responsible for
adhering to the given protocol prescribed by the server. Therefore the client should
behave in a server-conformist manner. This demand on the client naturally contains an
implicit demand on the server class: the server class must publish the context in which it
may be used, in a manner that is understandable by the clients (in other words, classes
must be well documented). Server classes should define their interfaces in such a way
that potential clients can fill the context. An internal context request within the server
class is always useful. Bertrand Meyer embedded a possible solution to this requirement
in the programming language Eiffel: methods can be defined using preconditions,
postconditions and variants.

Page 25 of 36
Introduction into Object Orientation - OOPs

4 Advantages and disadvantages

In this chapter, I want to clearly state the advantages of object-
orientation. To be more exact, I want to explain the advantages that
you can expect if you develop object-oriented software.

4.1 Quality

In his object-orientation "Bible", Bertrand Meyer names (see footnote

on page 4) ten external software quality factors, from which the first
five benefit the most from object-orientation:
 Correctness is the ability of software products to perform their exact tasks, as
defined by their specification.
 Robustness is the ability of software systems to react appropriately to abnormal
conditions.
 Extendibility is the ease of adapting software products to changes of specification.
 Reusability is the ability of software elements to serve for the construction of
many different applications.
 Compatibility is the ease of combinding software elements with others.

According to Bertrand Meyer, the following factors benefit to a lesser extent from object
orientation, but they should still be named for the sake of completeness:
 Efficiency is the ability of a software system to place as few demands as possible
on hardware resources, such as processor time, space occupied in internal and
external memories, bandwith used in communication devices.
 Portability is the ease of transferring software products to various hardware and
software environments.
 Verifiability is the ease with which inspection procedures can be created, in
particular test data and procedures for error trapping and handling.
 Integrity is the ability of a software system to protect its software elements from
unauthorized accesses and changes.
 Ease-of-use is the ease with which people of various backgrounds and
qualifications can learn to use software products and apply them to solve
problems. It also covers the ease of installation, operation and monitoring.

These themes naturally need to be backed-up. I will briefly do this in the following
sections. For a complete list of arguments, see the books listed below in the reading list.

4.1.1 Abstraction and encapsulation

Abstraction allows you to portray complex, real-world connections in

a simplified model, in such a way that unimportant details are ignored,
in order to better understand the overall system. Abstraction in the
object-oriented sense is mainly based on the classification of objects,
in contrast to the functional abstraction approach (for example, top-
down) of structured methods.
Page 26 of 36
Introduction into Object Orientation - OOPs

In object-oriented systems, classes are the smallest common units.

They encapsulate the functionality that they present to their clients. If
the capsule is well enough defined within its interface (see
Responsibilities), then the class/capsule can be fully tested locally. All
users of this functionality can now be sure that they are using an error
free - with regard to the context specification of the individual class -
functionality.
The class as capsule naturally has additional advantages. As long as its
interface is not changed in an incompatible manner, then maintenance
work, extensions and restructurings can be carried out locally. Ideally
this should not affect any users of the class.
By this stage you are probably already aware of the importance of the
concept of abstraction, and the class as a realization of an abstract
data type, as mentioned above and defined inClasses. As classes
realize abstract data types and generally correspond one to one with a
term from the private terminology of the software system users, then
validation of the functional correctness of a class is easier to
implement.

4.1.2 Inheritance and Polymorphism

With the help of inheritance and polymorphism it is generally easier to

implement extensions to a software system without having to make
changes to other programs/classes - in this context interfaces should
also be mentioned.
All other users of an existing class should not initially be affected by
the insertion of a new class into the inheritance tree. Thanks to
polymorphism this new class can take part in all previous operations.
Example of a client code:

DATA: ref_table TYPE REF TO cl_superclass occurs

10.
DATA: a_reference TYPE REF TO cl_superclass.

LOOP AT ref_table INTO a_reference.

CALL METHOD a_reference->a_method.
ENDLOOP.
At this moment it is irrelevant to the client, to which class the objects
in its internal table ref_table belong. As all methods have
implemented a_method , or it is available to all methods via their
inheritance tree, the user can happily leave his or her coding
unchecked when the inheritance tree is extended.
This example also functions with an interface. Just swap ref to
cl_superclass for ref to if_interface , then it still works. The

Page 27 of 36
Introduction into Object Orientation - OOPs

advantage is that the new class does not have to appear at all in an
inheritance tree. The implementation in the interface is sufficient.

4.1.3 Reusability

In my opinion, the reuse of components represents the best

opportunity of achieving quality. It is precisely reuse that is particularly
pushed in object-oriented systems. Due to encapsulation, many users
are forced to use existing components (classes, methods), with
precisely the following consequences:
 Increased productivity (it is notably quicker to reuse something than it is to
redevelop something and perhaps repeat the same mistakes twice)
 Quality of the reused components (a reused component is tested automatically)
 Easier extendibility (an extension of the reused component will immediately be
activated in all of these places)

4.1.4 Componentware

(Hardware - Software - Componentware)

For a long time now, efforts have been made in the OMG to standardize
communication between objects, or - better expressed - object
oriented program systems. Whereas the first attempts were laughable,
it has in the meantime become apparent, that the OMG is producing
serious approaches. It has defined a standard with CORBA (Common
Object Request Broker Architecture), which establishes the technology
which allows the object-oriented system objects to communicate with
each other.
However, the OMG is not only concerned with technology. Special
workgroups are busy defining business classes, which are intended to
have general validity. More exactly, the interfaces which these classes
should contain will be described. This is the first serious attempt to
standardize business software worldwide. In the long term - perhaps
even in the medium term - we can expect to see vendors who no
longer offer complete software systems but just individual components.
These components could communicate with one another on the basis
of CORBA, COM+ and Enterprise Java Beans, and so appear to be a
single entity, although the individual components have been
developed by different companies. You can compare this whole technique to a
PC. Components from different manufacturers are combined, so that the PC appears
as a single entity... at least that's the idea. ;-) In certain cases a class is a
component.

4.1.5 Interfaces

In object-oriented systems a large part of the work involves defining

interfaces. By this I don't mean the work that is required to formulate

Page 28 of 36
Introduction into Object Orientation - OOPs

an interface in a programming language. That is a relatively simple

task, the programmer's craft. No, the interesting thing about interfaces
is their identification (where are the actual connections between
components/classes?), the definition of responsibilities (which
responsibilities fall to the server, and which to the client?) and the
identification of where a specific functionality must be provided.
This requires a high level of cooperation between the various
workgroups, developers and departments, as well as a readiness to
compromise. One result is that genuine negotiations occur between
the parties involved (if you do this, then I'll do that!)..

5 Conclusion
This introduction to object-orientation is not a complete explanation of
the subject. It is only intended to give you a brief insight into object-
orientation. I hope I have inspired you to learn more. If this is the case,
then I can recommend several books. These books should help to give
you a deeper insight into the material.
Before you lay aside this introduction, I would like to give you one more
piece of advice:
Remember that you did not learn everything you know now in a few
days. Experience has shown that high project expectations are
generally not fully realized in the first project - unless you have project
team members who are experienced in object-orientation.

6 Appendix
6.1 Reading List

 Object-oriented Software Construction, Bertrand Meyer (Prentice Hall)

Deutsche Übersetzung: Objektorientierte Softwareentwicklung, ISBN 3-446-
15773-5
 Erfolgsschlüssel Objekttechnologie, Bertrand Meyer, Hanser Verlag, ISBN 3-446-
18697-2
 The Object Primer, Scott Ambler, SIGS Books, New York, 1995, Prentice Hall,
ISBN 0-13-242496-7
 Design Patterns, Elements of reusable object-oriented Software, E. Gamma, R.
Helm, R. Johnson, J. Vlissides, Addison Wesley, 1994, ISBN 0-201-63361-2
 UML Distilled, Applying the Standard Object Modeling Language, Martin Fowler
with Kendall Scott, Addison-Wesley, 1997, ISBN 0-201-32563-2
 Architecture, Process and Organization for Business Success, Ivar Jacobson,
Martin Griss, Patrik Jonsson, Addison-Wesley, 1997, ISBN 0-201-92476-5

ABAP/4 and ABAP Objects are registed trademarks of SAP AG, Java is registed
trademark of SUN Microsystems

Page 29 of 36
Introduction into Object Orientation - OOPs

You can find more information in Cetus Links.

If you have questions about ABAP Objects or ABAP/4 - instructions,
please feel free to contact me. Send a mail to
wolfram.puechert@futureobjects.de.

Page 30 of 36