ABAP OO Explained

ABAP data is the same as data.

It doesn't matter what module you're working on. The only type of information we can use in ABAP are:

• Character Data: A, B, C, and so forth or collections of these characters
• Numeric Data: 0, 1, 2, 3, and so forth.
• Byte Data: If you open it in notepad it looks a bit scary.

The data elements and domains are abstractions with intentions to represent particular types of business data in SAP. They're useful in the context of selection screens (F4, F1) or any tabular type data display such as with cl_salv_table as they provide an easy to way to apply descriptions to the columns, parameters, and select-options.

SAP has an extensive data element library deployed by any of the modules active on the application server. Combine that with customer developments and what ends up happening is a multitude of ways to represent the same type of information, for the same related SAP task and the same basic data type.

Even though the domains may share the same basic data type and length, things like conversion routines break compatibility between these containers of data. Passing these types of data containers through function modules that have the same basic data type yet a different data element will cause them to crash, even though the core essential character information remains the same. In some situations it's like saying 3 isn't 3.

To avoid this, I make use of the basic types that are the only type of data these data elements and domains could ever possibly represent.

data: my_string type string.
data: my_character type c.
data: my_integer type i.
data: my_float type f.
data: my_date type datum.
data: my_time type uzeit. 
my_string = 'this could be anything with characters and 123''s'.
my_character = 'c'.
my_integer = 24653.
my_float = '0.333'.
my_date = sy-datum.
my_time = sy-uzeit. 

If you make use of the basic data types supplied by ABAP than code is much easier to adapt similar objects to different purposes. a VBELN for example is character data of so many positions, so is VBELN_VN. The models and objects which contain this data during run time are most efficient when flexibly applied to the routines and tasks for making customer reports. The more flexible development objects are, the much easier it is to adapt for reuse, such as making use of existing repository classes for retrieving particular groups of data.

If the data needs to be passed to a particular function module or any standard SAP interface, the data can be converted on the spot to the respective data element without creating too much of a mess.

class cl_sales_document definition.
public section.
  data document_number type string.
  methods bapify_me.
endclass.

class cl_sales_document implementation.
  method bapify_me.
    data: bapi_vbeln type vbeln.
    bapi_vbeln = me->document_number. " type string.
    call function 'BAPI_BAPIFY' exporting vbeln = bapi_vbeln.
  endmethod.
endclass.

In some circumstances it'll add to a lot of code that'll mostly be assignments, but taking the 15 minutes to type out a few assign statements will save a lot of headache down the line. It helps keep the object reusable when multiple tasks are making use of the object.

Object Oriented ABAP

ABAP by nature is a procedural language. There is nothing negative intended. The language has just been established this way. In the majority of circumstances, especially concerning any database operations or interacting with standard SAP functionality, the most easily supported method is using structures, tables, and subroutines and function modules.

Even for those with experience in object oriented development ABAP can be tricky to properly adapt in particular situations. Some of the keywords which were permitted in ABAP reports are not supported in an object oriented context. The interfaces for functions don't work nicely with object attributes and methods, and the lack of method chaining support across all version can lead to a lot of code.

This kind of environment makes it difficult to effectively convey the true potential of developing things in an object oriented nature. The less experienced may try on their own to find that the result was less than satisfactory compared to their previous procedural work and could be against trying it again in the future. Because the language has already strongly established structures and tables as being the core essential of reports they're more naturally inclined to use what is already working for them.

The true power of object oriented development can't be explained by the technical jargon either because it means nothing to somebody who can't find a use for it. The point to remember is that encapsulation, abstraction, and inheritance mean nothing if you can't visualize a solution which you use these terms.

The most practical explanation, for somebody from an SAP perspective, is object oriented code strives to model program code after how you in real life would describe different types of "things", and the "actions" these things can do to interact with other "things". Classes encapsulate "things" and "actions" related to the "subject", a.k.a. the class name.

Let's talk about houses and the community. Take any community you want. Most likely there are homes everywhere where people live everywhere, millions of them. All sorts of different houses and homes. These houses need some kind of definition.

class cl_home definition.
  public section.
    data city type string.
    data street type string.
    data postcode type string.
endclass.

So we know what a house is now, it's a property in a city with a street and postcode associated with it. In real life, there aren't two address to one property (at least not in valid situations). If I tell you two different addresses, you know that I'm talking about two different homes.

data property_one type ref to cl_home.
data property_two type ref to cl_home.
create object property_one.
property_one->city = 'Somewhere'.
property_one->street = '100 There Street'.
property_one->postcode = '1111AA'.
create object property_two.
property_two->city = 'Somewhere'.
property_two->street = '1 Here Street'.
property_two->postcode = '2222AA'.

We're going to need some people to live in those homes too.

class cl_person definition.
  public section.
    data name type string.
    data age type i.
endclass.

And those homes have to be associated somehow to those properties so that we know when we're talking about a certain person or property we've got the right combination.

class cl_city_property definition.
  public section.
    data home type ref to cl_home.
    data residents type table of ref to cl_person.
endclass.

Of course we need some kind of governing body to manage to make sure these details stay in check and it's up to date. We'll also have to build a city hall to act as the representing body.

class cl_city_hall definition.
  public section.
    methods constructor
      importing cityname type string.
    methods register_residents
      importing city_property type ref to cl_city_property
      returning value(returning) type abap_bool.
  private section.
    data cityname type string.
    data properties type table of ref to cl_city_property.
endclass.

When new people want to move into the city at a particular property, they need to get permission from the city hall. However, I'm feeling very liberal and decided to let anybody in as long as the city is "Somewhere".

class cl_city_hall implementation.
  method constructor.
    cityname = cityname. " I forget if it's me or this, whatever
  endmethod.

  method register_residents.
    if ( city_property is not bound ). return. endif. " No property, won't happen.
    if ( city_property->home->city = 'Somewhere' ).
      append city_property to properties.
    else.
      return.
    endif.
    returning = abap_true.
  endmethod.
endclass.

data city_hall type ref to cl_city_hall.

The first wave of people move in. For simplicity sake, we're going to say there are two human beings who are going to move into those two homes we created earlier in Somewhere.

data human_one type ref to cl_person.
create object human_one.
human_one->name = 'Me'.
human_one->age = 30.

data human_two type ref to cl_person.
create object human_two.
human_two->name = 'Mi'.
human_two->age = 31.

Obviously, they gotta live somewhere. We have the home they both want, let's register it with the city hall. Prepare to fill out the paper work regarding the property...

data city_prop_one type ref to cl_city_property.
create object city_prop_one.
city_prop_one->home = property_one.
append human_one to city_prop_one->residents. 

data city_prop_two type ref to cl_city_property.
create object city_prop_two.
city_prop_two->home = property_two.
append human_two to city_prop_two->residents.

...Take a ticket. Wait for your number to be called...

data register_status type abap_bool.
register_status = city_hall->register_residents( city_prop_one ).
if ( register_status = abap_true ).
  write : / 'Human one lives in Somewhere now!'.
else.
  write : / 'Nope, sorry. Can''t live here.'.
endif.

register_status = city_hall->register_residents( city_prop_two ).
if ( register_status = abap_true ).
  write : / 'Human two lives in Somewhere now, too!'.
else.
  write : / 'Well, you can''t live here.'.
endif.

To recap, in real life two individual people saw two individual homes and decided to move into the respective home. They registered their property with the city hall by filling out the paper work and waiting for an approval. Afterwards, who cares.

In the ABAP report, we created two instances of a person object to represent the two people in real life. We also created two instances of a home. Two instances were created to represent the relation between the classes. An instance of city hall was created which represent the actions in "Somewhere".

We created individual objects to represent the people, homes, properties, and city hall. Each of these components are responsible for isolated parts of the program. people and homes serve as models which are designed to hold collections of associated data. properties acts as a composite containing a link between the two models. If we know the people than we can retrieve the property, and the same vice versa. city hall keeps this information in a table so that if need be in the future, the property can be retrieved.

This is what object oriented development is about. We approached the problem from a perspective that allows us to better envision the technical process of the program as well as the business case it's created to compliment. It's not about making peoples' lives miserable or add to the hassle of work but to give you a different mentality to approach challenges and problems.

When a particular business process is requested from ABAP developers it can always be broken down into more fundamental steps. These fundamental steps are considered and a design is thought up. The fundamental steps of the process are broken up into different ABAP classes where they individually share a responsibility in the greater picture.

Just programming using objects doesn't hold any direct benefit over procedural programming though. In not so many words the information above can be represented by the same program done procedurally.

types: begin of person_struct,
         name type string,
         age type i,
       end of person_struct.
types: begin of home_struct,
         city type string,
         street type string,
         postcode type string,
       end of home_struct.
types: begin of property_struct,
         home type home_struct,
         " Blah blah, you get the idea subroutines
         " and all the original statements in nice
         " neat code.

ABAP code is ABAP code. One method of development isn't better than the other and neither deserve the misconception it carries among developers. The true advantage comes from the perspective of seeing the development process from a different angle, the object oriented angle.

• Designing programs in an object oriented manner places you into a position to analyze the work more closely. Analyzing the job more closely means potential pitfalls and things to look out for are caught much sooner and considered ahead of time.
• Analyzing the job and breaking it down into objects helps you understand the task you're performing, and understanding that task, whichever it may be, will reflect in the program you create for the customer. Understanding the task better allows you to provide better advice and results in your work, and also assists when future additions are requested.
• Organized, clean, and well thought out objects save time for developers. Well thought out and designed objects can be reused much easily for others down the line.
• When objects are used effectively and designs are well considered it's much easier for those who haven't earlier been introduced to programs to be able to understand figure out what's going on. Object oriented programs describe themselves by object interactions, which are much easier to understand and follow.
• The objects which represent parts of a program can be developed by individual developers together at the same time without interrupting each other. If each class represents a responsibility in a program, and they're later linked together by their interface which is agreed upon ahead of time and changed in discussion, they don't need to work within the same file or code.
• The less time spent on details means more money can be used for refactoring, upgrading, improvement, or just 'nice-to-have' things. The money and time that was normally invested in error correction or bug fixes can be redirected to something more productive for the customer, for example new utilities.

In The End

ABAP code is ABAP code. There is no difference between ABAP code in a function module and ABAP code in a class method other than the context in which it is used. It's just a series of encapsulated statements that execute one after another.

Object oriented development is also something that's not a language or platform specific thing. The concepts learned from object oriented development can be applied to any language which has supports for a classes. The skills learned from object oriented development are what you take with you for all of your future assignments related to computer programming, and maybe even a personal philosophy.

C++.

class cl_person {
public:
  cl_person( int age, std::string name ) {
    age = age;
    name = name;
  }
  int getAge() {
    return age;
  }
  std::string getName() {
    return name; 
  }
private:
  int age;
  std::string name;
};
cl_person * person_one = new cl_person( 22, "guy" );
cl_person * person_two = new cl_person( 23, "girl" );

PHP

<?php
class cl_person {
  private $name;
  private $age;
  public function __construct( $age, $name ) {
    $this->age = $age;
    $this->name = $name;
  }
  public function getAge() {
    return $this->age;
  }
  public function getName() {
    return $this->name;
  }
}
$person_one = new cl_person( 22, 'guy' );
$person_two = new cl_person( 23, 'girl' );
?>

JSON, (an acronym for: "JavaScript Object Notation")

var person = {
  name : "",
  age : 0,
  jump : function() {
    alert('If I was real, I\'d jump.');
  }
}

Python

class cl_person:
  def __init__(self, name, age):
    self.name = name;
    self.age = age;

person_one = cl_person( 'guy', 23 );
person_two = cl_Person( 'girl', 24 );

Java

package bryan.nl;

public class Person {
  private String name;
  private int age;
  public Person( name, age ) {
    name = name;
    age = age;
  }
  public int getAge() {
    return age;
  }
  public String getName() {
    return name;
  }
}

SQL ok, so its not OO. Just go with it.

CREATE TABLE people ( age INT, name TEXT );
INSERT INTO people(age, name) VALUES ( 23, 'guy' ), ( 24, 'girl' );
SELECT * FROM people;