Regarding OOABAP

Former Member · ‎2007 Aug 13

hi

can anyone plz explain on OOABAP concepts in a small example program

seshatalpasai_madala · ‎2007 Aug 13

Hi,

Search help.sap.com for details.

Or goto Transaction ABAPDOCU for lot of example programs on ABAP Objects.

Regards,

Sesh

Former Member · ‎2007 Aug 13

Hi Sowjanya,

Though it is hard to teach all the OOABAP concepts within a single program, I am giving U a sample code to get started.

REPORT ZKIRAN_OOPS .

CLASS MATERIAL DEFINITION.

PUBLIC SECTION.

DATA: V1 TYPE STRING,

V2 TYPE I,

V3 LIKE V2.

TYPES: V5 TYPE STRING.

CLASS-DATA Y1 TYPE C.

TYPES:WA_MARA TYPE MARA.

DATA: IT_MARA TYPE TABLE OF WA_MARA.

METHODS:

GET_DATA EXPORTING E_TYPE TYPE MARA-MTART,

PUT_DATA.

PRIVATE SECTION.

DATA: X1 TYPE STRING.

TYPES: V15 TYPE STRING.

CLASS-DATA Y2 TYPE C.

ENDCLASS.

CLASS MATERIAL IMPLEMENTATION.

METHOD GET_DATA.

REFRESH IT_MARA.

SELECT * FROM MARA INTO TABLE IT_MARA UP TO 10 ROWS

WHERE MTART = E_TYPE.

ENDMETHOD.

METHOD PUT_DATA.

DATA:WA_MARA TYPE MARA.

CLEAR WA_MARA.

LOOP AT IT_MARA INTO WA_MARA.

WRITE:/ WA_MARA-MATNR.

ENDLOOP.

ENDMETHOD.

ENDCLASS.

DATA:MAT_INSTANCE1 TYPE REF TO MATERIAL.

DATA:MAT_INSTANCE2 TYPE REF TO MATERIAL.

PARAMETERS:P_TYPE LIKE MARA-MTART.

START-OF-SELECTION.

CREATE OBJECT MAT_INSTANCE1.

CALL METHOD MAT_INSTANCE1->GET_DATA

IMPORTING E_TYPE = P_TYPE.

CALL METHOD MAT_INSTANCE1->PUT_DATA.

SKIP.

If you require more material on this you can give your mail id.Reward points if this helps,

Kiran

Former Member · ‎2007 Aug 13

hi

In general every Object:• Contains Data. The data stores information that describes the state of the object.

• Has a set of defined behaviors. These behaviors are the things that the object “knows” how to do and are triggered by sending the object a message

• Has an Individual identity. This makes it possible to distinguish an object from another, just as it’s possible to distinguish one program variable from another.

Everything is an Object

• Everything is an object. Think of an object as a fancy variable; it stores data, but you can also ask it to perform operations on itself by making requests. In theory, you can take any conceptual component in the problem you’re trying to solve (dogs, buildings, services, etc.) and represent it as an object in your program.

• A program is a bunch of objects telling each other what to do by sending messages. To make a request of an object, you “send a message” to that object. More concretely, you can think of a message as a request to call a function that belongs to a particular object.

• Each object has its own memory made up of other objects. Or, you make a new kind of object by making a package containing existing objects. Thus, you can build up complexity in a program while hiding it behind the simplicity of objects.

• Every object has a type. Using the parlance, each object is an instance of a class, where “class” is synonymous with “type.” The most important distinguishing characteristic of a class is “what messages can you send to it?”

• All objects of a particular type can receive the same messages. This is actually a very loaded statement, as you will see later. Because an object of type circle is also an object of type shape, a circle is guaranteed to receive shape messages. This means you can write code that talks to shapes and automatically handle anything that fits the description of a shape.

This substitutability is one of the most powerful concepts in OOP.

Some language designers have decided that object-oriented programming itself is not adequate to easily solve all programming problems, and advocate the combination of various approaches into multiparadigm programming languages.

An object has an interface. Aristotle was probably the first to begin a careful study of the concept of type. He was known to speak of “the class of fishes and the class of birds.” The concept that all objects, while being unique, are also part of a set of objects those have characteristics and behaviors in Common was directly used in the first object-oriented language, Simula, with its fundamental keyword class that introduces a new type into a program (thus class and type often used synonymously).

Simula, as its name implies, was created for developing simulations such as the classic “bank teller problem.” In this, you have a bunch of tellers, customers, accounts, transactions, etc.

The members (elements) of each class share some commonality: every account has a balance, every teller can accept a deposit, etc. At the same time, each member has its own state; each account has a different balance, each teller has a name. Thus the tellers, customers, accounts, transactions, etc. can each be represented with a unique entity in the computer program. This entity is the object, and each object belongs to a particular class that defines its characteristics and behaviors.

So, although what we really do in object-oriented programming is create new data types, virtually all object-oriented programming languages use the “class” keyword. When you see the word “type” think “class” and vice versa.

Some people make a distinction, stating that type determines the interface while class is a particular implementation of that interface. Once a type is established; you can make as many objects of that type as you like, and then manipulate those objects as the elements that exist in the problem you are trying to solve.

Indeed, one of the challenges of object-oriented programming is to create a one-to-one mapping between the elements in the problem space (the place where the problem actually exists) and the solution space (the place where you’re modeling that problem, such as a computer).

But how do you get an object to do useful work?

There must be a way to make a request of that object so it will do something, such as complete a transaction, draw something on the screen or turn on a switch. And each object can satisfy only certain requests. The requests you can make of an object are defined by its interface, and the type is what determines the interface. The idea of type being equivalent to interface is fundamental in object-oriented programming.

Class

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.

Classes are templates for objects. You can either define a class locally in an ABAP program, or globally in the class library using the Class Builder tool in the ABAP Workbench. The class library is part of the R/3 repository. Class library classes are stored in special programs called class pools. A class pool is automatically generated for each global class that you create with the Class Builder. The Class Builder also generates the coding frame that defines the classes in the class pool. Global classes are visible to all ABAP programs of the R/3 System.

To define local classes in an ABAP program, such as a report or a function group, you must type the corresponding statements manually into the program. A local class is visible only inside the program in which it is defined.

The data, or variables defined within a Class are called instance variables. The code is contained within methods. Collectively, the methods and variables defined within a class are called members of the class. Thus, it is the methods that determine how a class’s data can be used.

Variables defined within a class are called instance variables because each instance of the class ( that is , each object of the class ) contains its own copy of these variables. Thus, the data for one object is separate and unique from the data for another.

More importantly “ You will never actually write the code for an Object: What you write is the pattern that is used to make objects ”

In ABAP Classes are defined between the CLASS and ENDCLASS statements. A class definition consists of a declaration part, in which the components are defined, and an implementation part, in which the methods are implemented.

CLASS c_user DEFINITION.

PUBLIC SECTION.

CLASS-DATA: instance_count type i.

DATA: id type i.

METHODS: CONSTRUCTOR,

display,

get_user RETURNING value(p_user) like sy-uname.

PRIVATE SECTION.

DATA: a_user like sy-uname.

ENDCLASS.

CLASS c_user IMPLEMENTATION.

METHOD CONSTRUCTOR.

a_user = sy-uname.

ENDMETHOD.

METHOD display.

WRITE 😕 a_user, id, instance_count.

ENDMETHOD.

METHOD get_user.

p_user = a_user.

ENDMETHOD.

ENDCLASS.

Class components

Possible class components are attributes, methods and events.

• Attributes

They are the internal data variables within a class. They can have any ABAP data type. We distinguish between instance attributes and static attributes. Instance attributes are declared by DATA and determine the state of an instance. You cannot work with instance attributes without creating an object first. Static attributes are declared by CLASS-DATA and determine the state of a class, which in a way applies to all instances. Static attributes form a data set that is shared by the whole class and all of its objects. You do not need to create an object to work with static attributes.

• Methods

They are the class’ procedures. They can access all class attributes and can therefore change the state of an object. They have a parameter interface similar to the interface of function modules. They can have named IMPORTING, EXPORTING, and CHANGING parameters, which can be optional or required and can be passed either by reference or by value. As with attributes, we distinguish between instance methods and static methods. Instance methods are declared by METHODS and can access all the attributes of a class. Static methods are declared by CLASS-METHODS and can only access the static attributes of a class.

Implementing Methods

You must implement all of the methods in a class in the implementation part of the class in a

METHOD <meth>.

...

ENDMETHOD.

block. When you implement the method, you do not have to specify any interface parameters, since these are defined in the method declaration. The interface parameters of a method behave like local variables within the method implementation. You can define additional local variables within a method using the DATA statement.

As in function modules, you can use the RAISE <exception> and MESSAGE RAISING statements to handle error situations.

When you implement a static method, remember that it can only work with the static attributes of your class. Instance methods can work with both static and instance attributes.

Calling Methods

To call a method, use the following statement:

CALL METHOD <meth> EXPORTING... <ii> =.<f i>...

IMPORTING... <ei> =.<g i>...

CHANGING ... <ci> =.<f i>...

RECEIVING r = h

EXCEPTIONS... <ei> = rc i...

The way in which you address the method <method> depends on the method itself and from where you are calling it. Within the implementation part of a class, you can call the methods of the same class directly using their name <meth>.

CALL METHOD <meth>...

Outside the class, the visibility of the method depends on whether you can call it at all. Visible instance methods can be called from outside the class using

CALL METHOD <ref>-><meth>...

where <ref> is a reference variable whose value points to an instance of the class. Visible instance methods can be called from outside the class using

CALL METHOD <class>=><meth>...

where <class> is the name of the relevant class.

When you call a method, you must pass all non-optional input parameters using the EXPORTING or CHANGING addition in the CALL METHOD statement. You can (but do not have to) import the output parameters into your program using the IMPORTING or RECEIVING addition. Equally, you can (but do not have to) handle any exceptions triggered by the exceptions using the EXCEPTIONS addition. However, this is recommended.

You pass and receive values to and from methods in the same way as with function modules, that is, with the syntax:

... <Formal parameter> = <Actual parameter>

after the corresponding addition. The interface parameters (formal parameters) are always on the left-hand side of the equals sign. The actual parameters are always on the right. The equals sign is not an assignment operator in this context; it merely serves to assign program variables to the interface parameters of the method.

If the interface of a method consists only of a single IMPORTING parameter, you can use the following shortened form of the method call:

CALL METHOD <method>( f).

The actual parameter <f> is passed to the input parameters of the method.

If the interface of a method consists only of IMPORTING parameters, you can use the following shortened form of the method call:

CALL METHOD <method>(....<ii> =.<f i>...)

.

Each actual parameter <f i > is passed to the corresponding

formal parameter .

•Events and Event Handlers

As earlier told ABAP supports object oriented features and also in addition to those features, ABAP supports Event handler methods.

So our primary question would be

Event Handler Methods

Before we step into Event Handler Methods, it is very important to understand and know how methods work in ABAP.

Event handler methods are special methods that cannot all be called using the CALL METHOD statement. Instead, they are triggered using events. You define a method as an event handler method using the addition

... FOR EVENT <evt> OF <cif>...

in the METHODS or CLASS-METHODS statement.

The following special rules apply to the interface of an event handler method:

o The interface may only consist of IMPORTING parameters.

o Each IMPORTING parameter must be an EXPORTING parameter of the event <evt>.

o The attributes of the parameters are defined in the declaration of the event <evt> (EVENTS statement) and are adopted by the event handler method.

http://www.sapgenie.com/abap/OO/index.htm

http://www.geocities.com/victorav15/sapr3/abap_ood.html

http://www.brabandt.de/html/abap_oo.html

Check this cool weblog:

/people/thomas.jung3/blog/2004/12/08/abap-persistent-classes-coding-without-sql

http://help.sap.com/saphelp_nw04/helpdata/en/c3/225b6254f411d194a60000e8353423/frameset.htm