Introduction into Object Orientation - OOPs Introduction into Object Orientation

(klick here to get the German version)

Contents
1 1.1 2 2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7 2.3.8 2.4 2.4.1 2.4.2 2.5 3 3.1 3.1.1 3.1.2 3.1.3 3.2 3.3 3.4 3.4.1 3.5 3.5.1 3.5.2 4 4.1 4.1.1 4.1.2 4.1.3 4.1.4

Introduction
Purpose

The Object-Orientation Concept

Observation Focus Basic Terminology Classes Objects / Instances Attributes Methods Construktor Object Identity and Reference Semantics Visibility Events Inheritance Polymorphism Generalization and Spezialization Interfaces

Softwareengineering the OO Development Process

OO Engineering aspects Responsibilities UML - The modeling Language Architecture The iterative Development Process Analysis Design Design Patterns Implementation Client-Server Responsibilities

Advantages and Disadvantages

Quality Abstraction and Encapsulation Inheritance and Polymorphism Reusability Componentware

Page 1 of 36

Introduction into Object Orientation - OOPs

4.1.5 5 6 6.1 Interfaces

Conclusion Reading List

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 Romanith, Oliver Stabel, Daniel Stephan, Katharina Wehrheim and Oliver Wiegert.

2
2.1

The Object-Orientation Concept

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 for object orientation. Bertrand Meyer developed the object-oriented programming language Eiffel and wrote the book "Object-oriented Page 2 of 36

Introduction into Object Orientation - OOPs

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. 2.3.2 Objects / Instances

Page 3 of 36

Introduction into Object Orientation - OOPs

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 Developers Guide to ObjetOrientation, 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 instancedependent. 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 IMPORTINGparameters. 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 Page 16 of 36

Introduction into Object Orientation - OOPs

to differentiate plants from animals. Therefore there are characteristics 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. Page 17 of 36

Introduction into Object Orientation - OOPs

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 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 Page 18 of 36

Introduction into Object Orientation - OOPs

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 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 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:
the concept for representing objects, error handling and much more.

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 socalled 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 Page 23 of 36

Introduction into Object Orientation - OOPs

interrupt his or her work and consider what needs to be done. 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 objectoriented 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

Advantages and disadvantages

In this chapter, I want to clearly state the advantages of objectorientation. 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 Page 26 of 36

Introduction into Object Orientation - OOPs

object-oriented sense is mainly based on the classification of objects, in contrast to the functional abstraction approach (for example, topdown) 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 (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. Page 27 of 36

Introduction into Object Orientation - OOPs

This example also functions with an interface. Just swap ref to cl_superclass for ref to if_interface , then it still works. The 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) Componentware

4.1.4

(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

Page 28 of 36

Introduction into Object Orientation - OOPs

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

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 objectorientation. 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
6.1

Appendix
Reading List
Object-oriented Software Construction, Bertrand Meyer (Prentice Hall) Deutsche bersetzung: Objektorientierte Softwareentwicklung, ISBN 3-44615773-5 Erfolgsschlssel Objekttechnologie, Bertrand Meyer, Hanser Verlag, ISBN 3-44618697-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

Introduction into Object Orientation - OOPs

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