more about object orientation concept

8/6/2019 More About Object Orientation Concept

1/30

Introduction into Object Orientation - OOPs

Introduction into Object Orientation(klick here to get the German version)

Contents1 Introduction

1.1 Purpose

2 The Object-Orientation Concept

2.1 Observation

2.2 Focus

2.3 Basic Terminology

2.3.1 Classes2.3.2 Objects / Instances2.3.3 Attributes

2.3.4 Methods2.3.5 Construktor2.3.6 Object Identity and Reference Semantics2.3.7 Visibility2.3.8 Events2.4 Inheritance

2.4.1 Polymorphism2.4.2 Generalization and Spezialization2.5 Interfaces

3 Softwareengineering the OO Development Process

3.1 OO Engineering aspects3.1.1 Responsibilities3.1.2 UML - The modeling Language3.1.3 Architecture3.2 The iterative Development Process

3.3 Analysis

3.4 Design

3.4.1 Design Patterns3.5 Implementation

3.5.1 Client-Server

3.5.2 Responsibilities4 Advantages and Disadvantages

4.1 Quality

4.1.1 Abstraction and Encapsulation4.1.2 Inheritance and Polymorphism4.1.3 Reusability4.1.4 Componentware

Page 1 of 36
http://www.futureobjects.de/content/intro_oo.htmlhttp://www.futureobjects.de/content/#1http://www.futureobjects.de/content/#1.1http://www.futureobjects.de/content/#2http://www.futureobjects.de/content/#2.1http://www.futureobjects.de/content/#2.2http://www.futureobjects.de/content/#2.3http://www.futureobjects.de/content/#2.3.1http://www.futureobjects.de/content/#2.3.2http://www.futureobjects.de/content/#2.3.3http://www.futureobjects.de/content/#2.3.4http://www.futureobjects.de/content/#2.3.5http://www.futureobjects.de/content/#2.3.6http://www.futureobjects.de/content/#2.3.7http://www.futureobjects.de/content/#2.3.8http://www.futureobjects.de/content/#2.4http://www.futureobjects.de/content/#2.4.1http://www.futureobjects.de/content/#2.4.2http://www.futureobjects.de/content/#2.5http://www.futureobjects.de/content/#3http://www.futureobjects.de/content/#3.1http://www.futureobjects.de/content/#3.1.1http://www.futureobjects.de/content/#3.1.2http://www.futureobjects.de/content/#3.1.3http://www.futureobjects.de/content/#3.2http://www.futureobjects.de/content/#3.3http://www.futureobjects.de/content/#3.4http://www.futureobjects.de/content/#3.4.1http://www.futureobjects.de/content/#3.5http://www.futureobjects.de/content/#3.5.1http://www.futureobjects.de/content/#3.5.2http://www.futureobjects.de/content/#4http://www.futureobjects.de/content/#4.1http://www.futureobjects.de/content/#4.1.1http://www.futureobjects.de/content/#4.1.2http://www.futureobjects.de/content/#4.1.3http://www.futureobjects.de/content/#4.1.4http://www.futureobjects.de/content/intro_oo.htmlhttp://www.futureobjects.de/content/#1http://www.futureobjects.de/content/#1.1http://www.futureobjects.de/content/#2http://www.futureobjects.de/content/#2.1http://www.futureobjects.de/content/#2.2http://www.futureobjects.de/content/#2.3http://www.futureobjects.de/content/#2.3.1http://www.futureobjects.de/content/#2.3.2http://www.futureobjects.de/content/#2.3.3http://www.futureobjects.de/content/#2.3.4http://www.futureobjects.de/content/#2.3.5http://www.futureobjects.de/content/#2.3.6http://www.futureobjects.de/content/#2.3.7http://www.futureobjects.de/content/#2.3.8http://www.futureobjects.de/content/#2.4http://www.futureobjects.de/content/#2.4.1http://www.futureobjects.de/content/#2.4.2http://www.futureobjects.de/content/#2.5http://www.futureobjects.de/content/#3http://www.futureobjects.de/content/#3.1http://www.futureobjects.de/content/#3.1.1http://www.futureobjects.de/content/#3.1.2http://www.futureobjects.de/content/#3.1.3http://www.futureobjects.de/content/#3.2http://www.futureobjects.de/content/#3.3http://www.futureobjects.de/content/#3.4http://www.futureobjects.de/content/#3.4.1http://www.futureobjects.de/content/#3.5http://www.futureobjects.de/content/#3.5.1http://www.futureobjects.de/content/#3.5.2http://www.futureobjects.de/content/#4http://www.futureobjects.de/content/#4.1http://www.futureobjects.de/content/#4.1.1http://www.futureobjects.de/content/#4.1.2http://www.futureobjects.de/content/#4.1.3http://www.futureobjects.de/content/#4.1.4


2/30


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 provideinterested readers with a brief overview of this new softwaredevelopment technique. The introduction does not provide a deepunderstanding of object-orientation and so should not be used as areplacement for a training course or for more detailed reading. ABAP/4programming knowledge will help you to understand this introduction.

ABAP/4 programming knowledge will help you to understand thisintroduction.The programming language ABAP/4 was renamed ABAPObjects after the introduction of object orientation.Many thanks to the following people, whose criticisms helped me towrite this document: Peter Dell, Andreas Flach, Petra Friedmann,Susanne Jung, Holger Meinert, Dietmar Nowotny, Claus von Riegen,Stefan Romanith, Oliver Stabel, Daniel Stephan, Katharina Wehrheimand Oliver Wiegert.

2 The Object-Orientation Concept

2.1 Observation

This introduction is strongly oriented towards the ABAP Objectsprogramming language. Note that many of the object-orientedconcepts described here are independent on the implementationlanguage.

2.2 Focus

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

technology - answers the question, "what is object-orientation", withthe following sentence:

Object-orientation is a software engineering technique.Bertrand Meyer: Object Success A Manager's Guide to ObjectOrientation, Prentice Hall 1995What Niklaus Wirth is for structured programming, Bertrand Meyer isfor object orientation. Bertrand Meyer developed the object-orientedprogramming language Eiffel and wrote the book "Object-oriented

Page 2 of 36
http://www.futureobjects.de/content/#4.1.5http://www.futureobjects.de/content/#5http://www.futureobjects.de/content/#6http://www.futureobjects.de/content/#6.1http://www.futureobjects.de/content/#4.1.5http://www.futureobjects.de/content/#5http://www.futureobjects.de/content/#6http://www.futureobjects.de/content/#6.1


3/30


software construction" (ISBN 3-446-15773-5). This book - some peoplecall it "the Bible of object-oriented programming" - founded hisreputation as the godfather of object-orientation.This view may be highly abstract, but from the management point ofview it sets the focus correctly. The introduction of object-orientation

into the software development process involves more than simplyusing 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 SoftwareEngineering, I will define some fundamental object-orientationterminology in the following sections.As is the case for every new technology, object-orientation hasproduced new terminology. On the one hand this was because therewere no adequate concepts, on the other hand existing concepts havesimply been given new names.

2.3 Basic Terminology

For a long time it was standard practice in software development tosubdivide software systems according to the system's functions.Object-orientation takes another approach. Instead of concentrating onfunctions, the object-oriented approach concentrates on dataabstractions 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 abstractconcepts Business Partner, Material, Transaction, Equipment or List. Classes realize anabstract data type.Classes contain components: Attributes, Methods and Events. Thesecomponents 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 bearwith me, the next section should help to clarify things.

2.3.2 Objects / Instances

Page 3 of 36
http://www.futureobjects.de/content/#3http://www.futureobjects.de/content/#3http://www.futureobjects.de/content/#3http://www.futureobjects.de/content/#3


4/30


An object is nothing more than an instance of a Class. For example, thebusiness partner Meyer is an instance of the Class Business Partner,the business partner Miller is another instance. All of the instances ofthe business Class Business Partner have something in common: theyoperate in a particular program context such as Business Partner.

Scott W. Ambler (The Object Primer The Application Developers 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 havefunctionality).

In ABAP Objects, objects are created with the command CREATE OBJECT. Thedeveloper 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 ofthe blueprint. Classes define the structure and behavior of all objects,which belong to them.

ObservationBefore I present the individual components of a Class, I will brieflymention 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 theClass Business Partner is not Mr. Miller himself, but rather an abstractand limited structure at a processing point in a program.Confusion between Class and Object is even more common. This isoften caused by poor communication between people. Many peopletalk or write about objects when really they mean Classes. This isprobably because the new paradigm is called Object-orientation andnot Class-orientation. If for example, the reuse of objects is being

Page 4 of 36


5/30


discussed, what is actually meant is the reuse of Classes. Unfortunatelythis often comes up in the literature. This makes the textsunnecessarily hard to understand.This inaccuracy is unfortunately also present in the BOR (BusinessObject 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 tofrustration.

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 haveasked yourself the question: How does an object know, that it

represents the person Meyer or Miller?This is the role ofAttributes. Attributes can take on values within anobject at runtime. The sum of all attributes and their values describesthe state of an object.In ABAP Objects attributes are defined in the definition part via the ABAP keywordDATA. In this example we have defined that the name of a business partner may be 50characters 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 Classdependent. Class attributes (Class attributes are also called staticattributes.)are not tied to a single instance, rather they "belong" to allinstances of the Class. These attributes exist only once in mainmemory. Instance-dependent attributes exist once per instance and are

tied to a single instance. For example, the attribute name is aninstance-dependent attribute, while the attribute instance_count

could be a Class-dependent attribute, in which the number of instancesof the Class cl_party could be noted.

In ABAP Objects you differentiate between instance-dependent and class-dependentattributes by means of the ABAP keywords DATA or CLASS-DATA to be used in thedefinition part:

CLASS cl_party DEFINITION.

Page 5 of 36
http://www.futureobjects.de/content/#2.3.7http://www.futureobjects.de/content/#2.3.7


6/30


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 ofthe objects belonging to the Class. Note that the attribute values donot guarantee the uniqueness of objects. During a program run manyobjects with the name Miller could be created. These objects would allhave - as in real-life - a separate identity and are different businesspartners who happen to have the same name.

2.3.4 Methods

As well as attributes, Classes have so-called Methods (you could sayfunctions instead of methods but, as mentioned in the introduction:New technologies require new names). While attributes describe thestatic structure of a class and its objects, Methods describe thebehavior of objects within a class. With the help of methods, thesystem provides operations, services and functions. Via methods, auser can manipulate the objects in a class or also the class itself. As forattributes, 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 thesyntax 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


7/30


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) TYPEBoolean.

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


8/30


Objects must be created at runtime (CREATE OBJECT instruction inABAP Objects). With their creation they also get their own identity.However, there are no fixed attribute values linked to the identity. Youare probably already wondering how objects get to their initial state.How do objects recognize theirinitial attribute values? How does an

object know during its creation that it is a Millerand not a Meyer?The Constructor concept exists specifically to answer this question.The constructor is a method which runs automatically during thecreation of an object. The constructor allows you to define IMPORTING-parameters.

In ABAP Objects you differentiate between instance-dependent and class-dependentconstructors via the language elements METHODSand CLASS-METHODS to be used inthe 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 parametersCLASS-METHODS: class_constructor.METHODS: constructor IMPORTING value(im_name) TYPE PName.DATA: name TYPE PName.

ENDCLASS.

CLASS cl_party IMPLEMENTATION.METHOD class_constructor.

...ENDMETHODMETHOD 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 executedCREATE 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 Objectslanguage instructions you have learned. You know the basic elementsof classes (attributes and methods), the differences between classesand their objects and how to express these in ABAP Objects.

Page 8 of 36


9/30


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 aboveexample, or the previous one (Make sure that the R/3 System is release4.5A or above.).

2.3.6 Object identity and reference semantics

With the help of the previous examples, you have established thatobjects belonging to a class are not created by the simple definition of

the class. Neither does the instruction DATA: instance ref tocl_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 newobject requested from the system. The reference instance then refers

to the object which has just been created. (The command CLEARinstance. at this point means that the object, to which the referencevariable refers, cannot be referenced. Therefore it can no longer beaddressed in this progam run. A Garbage Collector running in thebackground ensures that the object is removed from memory.This separates object-oriented implementation from classicimplementation. With the classic DATA instruction, main memory isreserved (which might never be used) and is preallocated the initialstate of the relevant variable. With the "object-oriented" instructionDATA-x-TYPE-REF-TO, only the intention to create an object isexpressed. 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 thedeciding factor.I want to explain in more detail the terms object identity and referencesemantics 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


10/30


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 thaninstance2.ENDIF.

* Attribute values are the same !!!IF instance->name = instance2->name.* This is the caseENDIF.

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

The first IF-Query (IF instance = instance2.)via the object referenceproduces the value false, although both objects have the sameattribute value "Miller". Note that in object-oriented languages thereference semantics apply for classes and their objects. Both objects

have the attribute value Name = Miller, but they are independentobjects with their own identity. The references therefore refer to twodifferent objects, although their attribute values are completelyidentical.If you want to compare two objects belonging to a class with oneanother, then you must write an individual method (for example, aclass method is_equal). Then you can compare the objects within thismethod.

2.3.7 Visibility

An important feature of object-orientation is the encapsulation ofattributes and methods - ultimately of functionality - in classes. A class

Page 10 of 36


11/30


guarantees its user specific properties and specific behavior. The sumof these properties is called the class interface. The Visibilitymechanism defines the class interface which is available to the users.There are three commonly defined types of visibility in object-orientedtechnology:

PublicThe relevant class component (attribute, method, event) is visible to all classes.

ProtectedThe relevant class component (attribute, method, event) is visible to the classitself and all inheritors. We will return to the terms Inheritor and Inheritance later in thisdocument (seeInheritance). What is important here is the difference between Public andPrivate.

PrivateThe relevant class component (attribute, method, event) is only visible to the classitself.

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

In this example the attribute name is hidden from the users. Access to the information itcontains 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
http://www.futureobjects.de/content/#2.4http://www.futureobjects.de/content/#2.4http://www.futureobjects.de/content/#2.4


12/30


DATA: name TYPE PName.

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

CALL METHOD instance->get_name IMPORTING ex_name = name.

ObservationIn this example I will demonstrate that with the help of visibility andthe 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 aglobal type PName (50 character text field), the class itself implementsthe name as a 75 character text field.

2.3.8 Events

Events are recognized in particular by programming interfaces of theGUIs (Windows, Motif, etc.), for example, you can "ask" the GUI totrigger an event if the user moves the mouse over a specific part of thescreen. When the event occurs you are telling the GUI to change theshape 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 ofcoding who is going to react to the event. Those components, whichwant to react to the event, register at the event runtime, in that theytell the runtime environment which method is to be executed when the

event is raised. In this way many components can register for anevent.Event handler methods can proceed synchronously as well asasynchronously. At present, ABAP Objects only supports synchronouscalling of the event handler method.Instances of the Class cl_class create an event object_created. The class methodprocess_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 thecurrent instance

Page 12 of 36


13/30


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 forall instances of the class cl_class. When an object is created for theclass cl_class (CREATE OBJECT instance.), the eventobject_created is raised in the constructor. The consequence is thatthe method process_event belonging to the class cl_class1 isexecuted.

2.4 Inheritance

The concept of inheritance is a new functionality which is made

possible by object-oriented software development. Similar mechanismsdo not yet exist in classical programming languages. So whatdifference 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 thestructure and behavior that has already been defined in one or more other classes(superclasses).

Page 13 of 36


14/30


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, askyourself the following questions: "What does the collection contain?Are there twin references to one object? Are the objects sortedaccording to any particular format?"You will quickly come to the conclusion that a single type of collectionis 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 goodopportunity to implement my new knowledge. I will implement each type of collection asa class!" In principle this approach is correct. However, you will soon establish that allcollections 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 theclass Collection. You then implement the individual types of collection in their ownclasses which are Subclasses of the class Collection. As a subclass, these classesinherit all of the components of the Superclass. Attributes, methods and events areinherited. In addition, you can implement additional attributes, methods and events in thesubclass. If a method from the Public Section orProtected Section of thesuperclass 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 undGeneralization and Specialization.

Page 14 of 36
http://www.futureobjects.de/content/#2.4.1http://www.futureobjects.de/content/#2.4.1http://www.futureobjects.de/content/#2.4.2http://www.futureobjects.de/content/#2.4.1http://www.futureobjects.de/content/#2.4.2


15/30


Inheritance tree for Collections

In the following example I have partially implemented the class

cl_collection and its inheritor class cl_set. The method addbelongingto the class cl_collection is redefined by the method addbelonging tothe 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 NOFIELDS.

IF sy-subrc 0.CALL METHOD SUPER->add EXPORTING im_item = im_item.

ENDIF.ENDMETHOD.

Page 15 of 36


16/30


ENDCLASS.

In the method add belonging to the cl_set the method add belongingto the superclass cl_collection is called via CALL METHOD SUPER->add.

ObservationIn order to avoid a class becoming a superclass, FINAL is added. Thisaddition says that no subclass may be defined for the relevant class. Inorder to avoid the situation where a class carries instances, there is theaddition ABSTRACT. Classes which carry this addition, should generallyserve as a superclass and contain a default implementation. Thisapproach 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 thesame name). This can occur via an inheritance relationship, in that themethods belonging to the superclass are redefined in the subclassesand implemented differently. ABAP Objects requires the method namesto be the same and the signature to be the same (signature = methodinterface).Polymorphism can be achieved in 2 ways:

Two independent classes implement methods with the same names and the samesignature with the intention, that the methods should be called dynamically from athird location.

A superclass implements a method, and in a subclass you want to reimplement thesame 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 conceptwas created precisely for such cases (see Interfaces).

2.4.2 Generalization and Spezialization

In the above section on inheritance, I have tried to explain inheritancein terms of technical software problems and their solutions (in the

Collections example). However, inheritance is not just a theoreticalsoftware creation. Its roots lie in the human character trait, which notonly classifies objects but also tends to fit them into a hierarchy.Consider an example from biology. We separate life forms into animalsand 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

Page 16 of 36
http://www.futureobjects.de/content/#2.5http://www.futureobjects.de/content/#2.5


17/30


to differentiate plants from animals. Therefore there are characteristicsthat all animals have in common, but not all plants. On the other hand,there are characteristics that all plants have in common, which do notapply for all animals.This principle of hierarchical classification, which lies at the heart of

human thought, is represented in object-oriented development by theinheritance 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 thesame components in an interface that you can in classes, howeverwithout implementing them.Classes can implement interfaces, and subsequently be addressed via

these interfaces. For example, a class cl_class can implement theinterface if_archive and thereby become archivable, or it canimplement if_workflow and thereby take part in a workflow. Thisopens an additional mechanism of polymorphism, however withoutbeing dependent on inheritance.This combination of classes with simpleinheritance and interfaces is more highly regarded by many experts than full multipleinheritance. Example: Java.In addition to object references (DATA: instance TYPE REF TOcl_class) there are also Interface References (DATA: reference TYPEREF TO cl_interface). A class which implements a specific interfacecan be addressed via this interface reference. Using such an interfacereference, you can access the components defined in the interface. Inthis way a user can view different classes through the 'spectacles' ofan interface and address them in a uniform manner.Interfaces therefore define specific, generic functionality. In contrast toclasses, interfaces generally have not only many users, but alsomany 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.

Page 17 of 36


18/30


METHOD if_interface~a_method....

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 referencesDATA: 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 castCALL METHOD ifref->a_method.

CREATE OBJECT instance1.

ifref = instance1. CastCALL METHOD ifref->a_method.

3 Software Engineering - the OODevelopment Process

The confusion mentioned in Objects / Instances (objects versus classes,software objects versus real objects) is also due to additional reasonsthan 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 implementationare 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 theexternal system - e.g. financial accounting or customer administration -using an adequate software concept.This model closes the gap between problem and solution. Bertrand Meyertalks about the impedance problem of classic engineering techniques. Users and

Page 18 of 36


19/30


developers talk about the same elements (business partner, material).Analysis, design and implementation are "talking the same language".Method inconsistency is not apparent and not at all inherent in theprocess.

3.1 OO Engineering Aspects

Before I describe the individual phases of the development process inmore detail, I want to describe several fundamental aspects of OOengineering.

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 eachfunctionality that is required, you should clarify in which area ofresponsibility of a class/object the required functionality lies. This classshould then also offer a relevant service (method, event etc). If theresponsibility lies outwith your own area, then correspondingcommunication is required. The individual developers may have to talkwith each other, in order to decide how the functional responsibilityshould be allocated.

3.1.2 UML - The Modeling Language

Page 19 of 36


20/30


Graphic: the history of UML

The modeling language UML (Unified Modeling Language) was chosenas the standard by the OMG (Object Management Group, see also

section Componentware) in 1997. It allows for the standardrepresentation of the different aspects of an object-oriented softwaremodel. Therefore it shows aspects of componentization, packaging,relationships and more.The following types of diagrams are standardized in UML:

Use Case DiagramThis diagram describes Use Cases (also known as scenarios) and the relevantactors that participate in these use cases.

Class DiagramThe central diagram for representing static structure of classes, interfaces and

packages. Sequence DiagramDiagram representing message sequences (messages are the basic means ofcommunication between objects. In the implementation, messages are usuallyrealized by method calls.)

State DiagramState diagram for classes.

Page 20 of 36


21/30


Activity DiagramDiagram to represent system behavior (particularly suitable for workflow andparallel processes).

Collaboration DiagramDiagram of static and dynamic representation of communications relationships

between classes or objects. Object Diagram

This diagram models relationships between objects, which are not directly visiblein the class diagram

Component DiagramDiagram representing development components and their dependencies

Deployment DiagramDiagram representing hardware and software dependencies

I can only briefly explain the UML in this section. The next pictureshows a class diagram. If you want more information on the UML, we

recommend the book: "UML Distilled Applying the Standard ObjectModeling 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 crucialsignificance. The different classes must be constructed according tothe same architectural rules. At this stage I should really define what is meantby architecture. However, from the point of view of this paper a rough idea issufficient. Architecture could include the transaction concept, the database concept,

Page 21 of 36


22/30


the concept for representing objects, error handling and much more. If this is notthe case, then it is harder to get classes to communicate with oneanother. It is particularly difficult to integrate different classes into afunctioning software package.In classic programs, data is passed from interface to interface. Where a

program has to use two non-matching interfaces, a conversion routinecan easily be inserted and you can carry on.This is no longer possible in object-oriented systems. The calling classno longer has the authority to transfer data between two interfaces. Itonly has references to objects, whose data it does not know. Dataconversion by the calling class is no longer possible.Bertrand Meyer considers the term "architecture" to be so important inthe object-oriented environment, that he places the ArchitecturePrinciple first in his list of the ten fundamental concepts of objecttechnology:

Object technology mainly influences the architecture of software systems.As well as this uniform architecture, is it just as important that theclasses belonging to a class library are tailored according to the samecriteria, such as granularity, separation into main- and helper classes,equivalent inheritance trees etc. A conceptionally inconsistent classlibrary has the same negative effects as classes that are createdaccording to different architectural principles. It is difficult for classesat different levels of abstraction to communicate with one another.Imagine a real-life example. A bricklayer and an architect havecompletely different views of a house. While the bricklayer knows

every stone of the wall he has built, the architect is only interested inthe result, that is the wall must be built according to plan. If thearchitect had to concern himself with every single stone or every singleroofing tile of a house, then the house plans would take far too long toproduce.

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 severaltimes, 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


23/30


After validation (e.g. after the first increment, you can see that the project aim isachievable), the next increment can be carried out for the next most importantproject 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 hardlychanged from the classic development process. The main tools for theanalysis phase are the now standardized - but previously familiar - UMLUse 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 followingresults 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, RalphJohnson, John Vlissides: Design Patterns - Elements of Reusable Object-orientedSoftware, Addison-Wesley, ISBN: 0-201-63361-2), the authors write:

Designing object-oriented Software is hard, and designing reusable object-orientedsoftware is even harder.

... and that is also my opinion. But don't worry, the design has notnecessarily 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 simplynot visible at the design phase.

The sentence: "We'll make the decision at implementation when weknow this or that" is often heard during the modeling phase, whendecisions are being avoided.However, these (postponed) decisions must, for the object-orientedprocedure model, be decided during the modeling phase. Anincomplete class model has a significantly greater negative effect onthe implementation. Where there is an obvious gap in the design, animplementer cannot quickly "program something in", but must first

Page 23 of 36
http://www.ambysoft.com/ooModelingProcess.pdfhttp://www.futureobjects.de/content/#3.1.2http://www.ambysoft.com/ooModelingProcess.pdfhttp://www.futureobjects.de/content/#3.1.2


24/30


interrupt his or her work and consider what needs to be done.Responsibilities - whether organizational (which developer needs tocontribute to the solution) or implementation-specific (which class isresponsible for the additional required functionality) - must be clarifiedand 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 seconditeration. However, the gaps themselves must be the subject ofmodeling.In this context, it is naturally very important to have tools availableduring the modeling phase, which should make the modeler's taskeasier. Luckily for us Gamma and his colleagues have done the pioneerwork and brought the concept of Design Patterns into the discussion.

3.4.1 Design Patterns

Design patterns were introduced by an architect (!), ChristopherAlexander. He described recurring problems in building constructionand 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 thissolution a million times over, without ever doing it the same way twice.Christoper Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-king, ShlomoAngel: 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 tothen reside in technical literature. On the contrary: in order torecognize design patterns you need to look at many, many solutions,recognize a common pattern, abstract this pattern and then simplywrite up the Design Pattern.

Design patterns are discovered and not developed.

Design patterns have - as well as reusability - a further positivecharacteristic: 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 withdesign 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 principlesis not intended to be complete and is only intended to give a briefinsight into object-oriented implementation.

Page 24 of 36


25/30


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 ofthis 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 theclient. I call a method and expect a result. It doesn't matter to me howthis result is reached. The main thing is that the method delivers whatis requested. The implementation details of the foreign class shouldonly interest me in exceptional cases.In principle, as a client I should only cooperate with the publicinterfaces of the other classes. As a server, I should only publish thosecomponents (attributes, methods, events), whose existence I want tomake 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 forthe 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 notdesirable in object-oriented software systems.This statement alsoindirectly defines the maximum size of a class. It must not be - withregard to the coding as well as the functionality - so big that anindividual 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 foradhering to the given protocol prescribed by the server. Therefore the client shouldbehave 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 itmay be used, in a manner that is understandable by the clients (in other words, classesmust be well documented). Server classes should define their interfaces in such a waythat potential clients can fill the context. An internal context request within the serverclass is always useful. Bertrand Meyer embedded a possible solution to this requirementin the programming language Eiffel: methods can be defined using preconditions,postconditions and variants.

Page 25 of 36


26/30


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 thatyou can expect if you develop object-oriented software.

4.1 Quality

In his object-orientation "Bible", Bertrand Meyer names (see footnoteon page 4) ten external software quality factors, from which the firstfive benefit the most from object-orientation:

Correctness is the ability of software products to perform their exact tasks, asdefined by their specification.

Robustness is the ability of software systems to react appropriately to abnormalconditions.

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 objectorientation, 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 possibleon hardware resources, such as processor time, space occupied in internal andexternal memories, bandwith used in communication devices.

Portability is the ease of transferring software products to various hardware andsoftware environments.

Verifiability is the ease with which inspection procedures can be created, inparticular test data and procedures for error trapping and handling.

Integrity is the ability of a software system to protect its software elements fromunauthorized accesses and changes.

Ease-of-use is the ease with which people of various backgrounds andqualifications can learn to use software products and apply them to solveproblems. 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 followingsections. 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 ina simplified model, in such a way that unimportant details are ignored,in order to better understand the overall system. Abstraction in the

Page 26 of 36
http://www.futureobjects.de/content/#6.1http://www.futureobjects.de/content/#6.1


27/30


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.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 (seeResponsibilities), then the class/capsule can be fully tested locally. Allusers of this functionality can now be sure that they are using an errorfree - with regard to the context specification of the individual class -functionality.The class as capsule naturally has additional advantages. As long as itsinterface is not changed in an incompatible manner, then maintenancework, extensions and restructurings can be carried out locally. Ideallythis should not affect any users of the class.By this stage you are probably already aware of the importance of theconcept of abstraction, and the class as a realization of an abstract

data type, as mentioned above and defined inClasses. As classesrealize abstract data types and generally correspond one to one with aterm from the private terminology of the software system users, thenvalidation of the functional correctness of a class is easier toimplement.

4.1.2 Inheritance and Polymorphism

With the help of inheritance and polymorphism it is generally easier toimplement extensions to a software system without having to makechanges to other programs/classes - in this context interfaces should

also be mentioned.All other users of an existing class should not initially be affected bythe insertion of a new class into the inheritance tree. Thanks topolymorphism this new class can take part in all previous operations.Example of a client code:

DATA: ref_table TYPE REF TO cl_superclass occurs10.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 haveimplemented a_method , or it is available to all methods via theirinheritance tree, the user can happily leave his or her codingunchecked when the inheritance tree is extended.

Page 27 of 36
http://www.futureobjects.de/content/#3.1.1http://www.futureobjects.de/content/#2.3.1http://www.futureobjects.de/content/#3.1.1http://www.futureobjects.de/content/#2.3.1


28/30


This example also functions with an interface. Just swap ref tocl_superclass for ref to if_interface , then it still works. Theadvantage is that the new class does not have to appear at all in aninheritance tree. The implementation in the interface is sufficient.

4.1.3 Reusability

In my opinion, the reuse of components represents the bestopportunity of achieving quality. It is precisely reuse that is particularlypushed in object-oriented systems. Due to encapsulation, many usersare forced to use existing components (classes, methods), withprecisely the following consequences:

Increased productivity (it is notably quicker to reuse something than it is toredevelop 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 standardizecommunication between objects, or - better expressed - objectoriented program systems. Whereas the first attempts were laughable,it has in the meantime become apparent, that the OMG is producingserious approaches. It has defined a standard with CORBA (Common

Object Request Broker Architecture), which establishes the technologywhich allows the object-oriented system objects to communicate witheach other.However, the OMG is not only concerned with technology. Specialworkgroups are busy defining business classes, which are intended tohave general validity. More exactly, the interfaces which these classesshould contain will be described. This is the first serious attempt tostandardize business software worldwide. In the long term - perhapseven in the medium term - we can expect to see vendors who nolonger offer complete software systems but just individualcomponents. These components could communicate with one another

on the basis of CORBA, COM+ and Enterprise Java Beans, and soappear to be a single entity, although the individual components havebeen developed by different companies.You can compare this wholetechnique 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 aclass is a component.

4.1.5 Interfaces

Page 28 of 36


29/30


In object-oriented systems a large part of the work involves defininginterfaces. By this I don't mean the work that is required to formulatean interface in a programming language. That is a relatively simpletask, the programmer's craft. No, the interesting thing about interfacesis their identification (where are the actual connections between

components/classes?), the definition of responsibilities (whichresponsibilities fall to the server, and which to the client?) and theidentification of where a specific functionality must be provided.This requires a high level of cooperation between the variousworkgroups, developers and departments, as well as a readiness tocompromise. One result is that genuine negotiations occur betweenthe parties involved (if you do this, then I'll do that!)..

5 Conclusion

This introduction to object-orientation is not a complete explanation ofthe 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 giveyou a deeper insight into the material.Before you lay aside this introduction, I would like to give you one morepiece of advice:Remember that you did not learn everything you know now in a fewdays. Experience has shown that high project expectations aregenerally not fully realized in the first project - unless you have projectteam 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

Erfolgsschlssel 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

Page 29 of 36


30/30


ABAP/4 and ABAP Objects are registed trademarks of SAP AG, Java is registedtrademark of SUN MicrosystemsYou 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

[email protected] .
http://www.cetus-links.de/~cetus/software.htmlmailto:[email protected]://www.cetus-links.de/~cetus/software.htmlmailto:[email protected]

more about object orientation concept

Documents