Object Orientation in ABAP

ABAP had started out as a procedural language primarily for report programming. However later on when the advantages of object oriented concepts were evident to the programming world, SAP introduced object orientation into ABAP and hence ABAP Objects emerged from 4.5 onwards.

For the object-oriented part, only those OO concepts that had proved their worth for enterprise application development in other languages like C++, JAVA and Smalltalk where adopted in ABAP. Hence you will find variations in the implementation of few of the concepts in SAP from their original implementations in other object-oriented languages.

The 4 Main Principles of Object Orientation are

1. Encapsulation

2. Inheritance

3. Polymorphism

4. Abstraction

Out of these concepts ABAP Objects supports Encapsulation, Inheritance and Abstraction in the pure sense of Object orientation. However, Polymorphism as it was originally proposed does not completely deal with business programming hence SAP has adopted only part of the original Polymorphism proposals.

Let’s explore each of these Concepts in further detail.

Before we start few points to Note:

• Since this a discussion about Object Orientation and its adoption into ABAP, I am not going to go into specific code implementations. To know how to do the actual implementation you can refer to help.sap.com. There are many other good blogs on this topic, a few of these resources I have mentioned in the bottom of this blog.
• Few of the examples I have used here have been described in SAP standard study documents. I have referred to the same examples here for easier understanding.

OK,  So, let’s start with Abstraction first.

Abstraction

Abstraction as per the dictionary means existing in thought or as an idea but not having a physical or concrete existence.

An example of abstraction is the word animal. There really is nothing that you can see or touch which is literally an animal. What you see around you are specific implementations of animal, as in horse, cow, dog, cat etc.

Another example would be the VEHICLE Class.

Imagine a rental company which rents out 3 types of vehicles.

1. Cars, trucks and buses
2. Notice that there is nothing physical known as a Vehicle. If you walk up to the front desk of this rental company and say “I would like to rent a vehicle”, the first thing they would ask you is what kind of vehicle a car, truck or a bus? In-other words vehicle is abstract. It’s not physical or concrete.

Then what’s the need of having vehicle class if it has no physical instance.

Well, think about it for a minute. Why do we use the term vehicle in our normal conversation instead of saying car, truck or bus. Because we know that sometimes in conversations we don’t want to go into the specifics. We want to make a generalization. We want to refer to the common elements and leave the extra stuff out. You make a generalization when you tell your friends “I won’t be able to attend the party tonight; my relatives are coming over for dinner”. Notice here you haven’t given the details of which relative you are referring to and likewise your friends don’t need to know the specifics either. It could be your aunt or uncle from far off, for all they care.

This is called Generalization.

Abstraction helps us use Generalizations in our software code as well. A pure object oriented language should support Abstraction.

So, in the case of the rental company we could have an abstract class called as CL_VEHICLE. In ABAP you define an abstract classes with the ABSTRACT keyword.

Note:

• Both, classes and methods can be ABSTRACT.
• Static methods cannot be ABSTRACT (Why ? think and answer in comment please)

OK, So since you classify CL_VEHICLE as abstract hence you cannot instantiate it, just like there is no instantiation of any of your relatives. But you can add all the generic methods and attributes to it. Just like all your relatives share the same attribute (annoying but loving).

Our Abstract CL_VEHICLE class could have attributes and methods something like this

Note:

• The plus sign preceding the attributes and the methods indicate that it is public, accessible from anywhere, within the class and outside.
• Alternatively the minus sign indicates that it is private, accessible only within the class.
• A # symbol would mean the attribute/method is protected
• The method get_count is a static method to keep a track of the number of active instances of vehicles currently available in the program. Static methods are defined with the key word CLASS-METHODS.
• Similarly the attribute N_O_VEHICLE is a static attribute. An attribute is defined static with the keyword CLASS-DATA.
• Statics are indicated with an underline.

Now since we want to make CL_VEHICLE Abstract, we would need to call it an Abstract class such that no instantiation of the class is possible. An instance of a class is called an Object, and we use the CREATE OBJECT keyword to instantiate an object. But since there is nothing known as vehicle hence there can be no runtime object of vehicle. In ABAP, we use the ABSTRACT keyword to define an abstract class.

This brings us to the next characteristics of Object orientation which is called Inheritance.

Inheritance

You have inherited certain attributes from your mom and dad. Maybe you are very patient or you are very hard-working and in India people say “Jaroor apne Dada pe gaya hai”

Google goofed up the translation but well you get the idea.

What ideally, we equate this to, is that everyone of us has picked up traits and features from our parents and unless we are talking about the Bollywood movies which are common for their Father/Son double roles (remember Bahubali), most of the times sons and daughters are not perfect carbon copies of their fathers or mothers. They only imbibe certain characteristics such as skin color, hair texture etc. the rest of the characteristics are their own. In other word’s they inherit some characteristics from their parents but also have many of their own characteristics.

Similarly, in software development you would want to derive certain attributes of the parent class also known as super class into the child class also known as sub class.

This is called Inheritance.

One point to note is that in ABAP a sub-class cannot inherit from multiple parents. For this purpose we have INTERFACES to extend the generalization concept.

Coming back to our example of the CL_VEHICLE then, we said that the rental company deals in Cars, Trucks and Buses. We also know that all these three kinds of locomotives are actually vehicles with some specific additional attributes and functionality, different from each other, but they all have the same generic attributes and functionality as their parent vehicle class.

Hence we make these classes inherit from their parent class.

So we get a diagram as follows.

And here we get introduced to another term in OO called as Specialization. Which is actually the reverse of Generalization.

We had generalized our relatives in our earlier conversation with our friends however you would get specific when you say “Lakshmi Aunty is too nosy, she is always concerned about my marriage”. In this case you did not generalize but were specific about one of your relatives. Similarly when you talk to the rental company you cannot be generic and say I want to rent a vehicle. They would not know what you mean by vehicle. They want to know exactly which vehicle, A car, truck or Bus, so they can keep it ready for you when you arrive. But also realize that the each of these have specific attributes in addition to the common attributes.

The beauty of generalization/specialization is so wonderful that it helps you make your software code flexible enough for future needs. If your sister has a baby, you get a totally new kind of relative which you never ever had, your niece/nephew, notice that the generalization still holds. It is still a relative in your bucket loads of relatives, however it is also specific in that it is your junior who would not annoy you but you would love to be with (in most cases at-least).

In ABAP inheritance from super-class is implemented using the INHERITING FROM Keyword.

Inheritance is fine but sometimes you don’t want the parent class behavior to be inherited totally by the child class. In other word’s the parent class CL_VEHICLE has a method called ESTIMATE_FUEL in the vehicle class, but the sub-class(CL_CAR) estimates fuel in a different way than let’s say a CL_BUS, then we don’t want to carry the ESTIMATE_FUEL from the parent CL_VEHICLE implementation to the child. In such cases we would have to redefine the method. In object orientation this is called method Overriding. In ABAP you redefine child methods with the REDEFINE keyword.

Few points to mention here

Point 1: With redefinition there is also a concept called as Overloading. Method Overloading happens when you define the same method but with different signatures and thus different implementation. This is not supported in ABAP Objects. In Java and C++ however this is very common.

Same method name but different implementations accepting different datatypes within the same class.

Point 2: Sometimes you do not want any of the child classes to redefine a particular method of the parent class. In that case you need define the method with the FINAL keyword. Even classes can be FINAL.

Point 3: In some cases you don’t want multiple instances of the same class in the program execution. Typical case is when you are dealing with an employee self-service application. (ESS). When the employee logs in to access their data, you don’t want another object instance of the employee other than the one who has logged in at that time. Remember the SY-UNAME is the employee we want to store at runtime as there can be only one SY-UNAME at one time. This is achieved with the use of the Keyword CREATE PRIVATE in addition to FINAL and instantiating it using its static constructor. Such classes are called Singleton classes.

Point 4: There is also the concept of FRIENDSHIP, EXCEPTION Classes, Events and Propagation, Object Sharing etc. etc. but if I keep discussing all that then we will be going into too much details and ultimately off the topic, so let’s stick with topic at hand.

This brings us to the third characteristics of Object Orientation known as Polymorphism.

Polymorphism

Polymorphism happens when the same method has different forms.
In Object Orientation pure polymorphism supports both overloading as well as method overriding.

We already learnt what is overloading and overriding in the above discussion and we learnt that ABAP supports overloading but not overriding.

Java supports pure polymorphism, however ABAP only supports overloading.

Here I will introduce you to two of the major and powerful constructs in Object Orientation in ABAP, which are derivatives of overloading and which I have used quite often called UP-CASTING and its opposing DOWN-CASTING.

UP-CAST (Widening Cast)

Because of Inheritance, variables of super-class can also refer to sub-class instances at runtime.

This is often referred to as Up-Casting.

Let’s understand Up-Casting better with a few examples.

Example 1: (based on the above class diagram)

 

Example 2 : (based on our earlier vehicle discussion)

Let’s say we have a method called ESTIMATE_FUEL in LCL_VEHICLE class as such

ESTIMATE_FUEL = DISTANCE * BASE_FACTOR

Consider that BASE_FACTOR is a constant value of 5.

Therefore ESTIMATE_FUEL will be 500 if the distance is 100 miles.

Since LCL_CAR is a sub-class of LCL_VEHICLE hence ESTIMATE_FUEL will also be present in LCL_CAR and the estimated fuel value for the car will also be 500. However since CAR is a specialized form of vehicle hence let say we redefine it’s estimated_fuel calculation to incorporate another constant CAR_FACTOR = 5. So estimate_fuel for a car becomes

ESTIMATE_FUEL = DISTANCE * BASE_FACTOR * CAR_FACTOR.

Thus Estimated_fuel for car will be 2500 for the same distance.

In this case we will have to redefined the estimate_fuel method of the parent into the child.

Similarly the LCL_BUS class is a sub-class of LCL_VEHICLE hence its estiamte_fuel will also be 500. We will redefine this method in the LCL_BUS class also to take into consideration the BUS_FACTOR which has a constant value of 10.

So the estimated fuel for a bus will be calculated as follows

ESTIMATE_FUEL = DISTANCE * BASE_FACTOR * BUS_FACTOR.

Thus estiamted_fuel for bus will be 5000 for the same distance of 100 miles.

OK, so now I have explained you the scenario.

Now imagine the rental company is planning to rent out X Cars and Y buses for an upcoming event. The event is happening out of town atleast 100 miles away.

The program therefore at runtime instantiates the appropriate vehicles and stores their references into an internal table. But since we want to store reference of all the vehicles into the same internal table. Hence we will define the table column as type LCL_VEHICLE.

Now to calculate the estimate_fuel for all the vechiles we simply need to loop through the internal table and call the Estimate_fuel for each vechile as such.

TOTAL_FUEL_CONSUMPTION = TOTAL_FUEL_CONSUMPTION + ESTIMATED_FUEL.

This way we need not bother with what is exactly stored in the internal table, whether it is car or bus the system will take care of calling the appropriate estimate_fuel method implementation based on the object.

This is called UP-CASTING because you are pointing a child reference to a parent reference.

R_VEHICLE = R_CAR.

and because the target variable r_vehicle can refer to a wide range of object.

It should be evident now that with down-casting you are moving a reference of a parent class to a child class.

Incase upcasting we had  R_VEHICLE = R_CAR.

In downcasting we would do R_CAR1 ?= R_VEHICLE.

Which means you are reassigning the reference of r_car back to r_car1.

The syntax for down casting in ABAP is

MOVE .. ?TO or its short form ?=

When would you use such a down-casting.

This could be used in the case when you have a generic reference and now you want to use the specific method from the generic reference. In that case you would first down-cast the generic reference to a specific reference type which has the method and then call the method through it.

However remember you cannot convert an R_CAR variable to a R_BUS variable using down-cast

so the folowing will throw an exception of type cx_sy_move_cast_error.

R_VEHICLE = R_CAR

R_TRUCK ?= R_VEHICLE.

Because now you are moving a truck reference to a car through vehicle.

Example of down-casting.

With this we come to the end of this blog to understand the various concepts in SAP’s ABAP Objects and the implementation of Object Orientation in APAP.

If you have any questions, comment or want more clarifications please let me know in the comments section below. I will try to elaborate on this as much as I know. If you have used ABAP Objects in your own implementations I would love to know that as well. Feel . And if you liked this article don’t forget to share it.

---

Blogs Referred:

1. Polymorphism : ABAP vs JAVA explained at www.saptechnical.com
2. Download the ABAP Objects – Basics Guided Tutorial by Horst Keller.
3. The whole ABAP Objects tutorials series at SAP Technical
4. Object Oriented Concepts in Java I found interesting at www.beginnersbook.com.
5. Lots of discussions on ABAP Objects can be found at www.zevolving.com
6. Good Blog on SCN explaining Singleton Pattern Implementation in ABAP.

I will add more interesting links as I get them.