Must-know modularization basics from ABAP programming tutorial

Separation of concerns

Separation of concerns is a principal used to separate a program into different layers, each with its own function. Imagine an ABAP program that was created to report on some data from the database. You could break that program into three different parts, one part to read the data from the database, another part to process the data, and a third part to display the results, as shown conceptually in Figure 6.1.

When you break your program into these three different sections, you then have one place to make changes to any of those functions.

Procedural programs. Back in the ancient days of computing, people would write long programs using punch cards that had to be executed from the beginning to the end and probably scheduled to run at a certain time. Today, applications are used by people in real time, which means that you need to change your application to meet the user's sometimes crazy expectations. Programs designed to run from the beginning to end are called procedural programs.

In a typical ABAP journey, it's normal to see an old program written in a procedural format -- and then you'll hear from a user that the program is supposed to process data in some way that isn't working.

You'll have to go through the long process of reading the program and debugging to figure out where the data is changed, only to find that the data is read and changed all over the place.

Why use separation of concerns? In order to avoid writing procedural nightmare programs, use the separation of concerns principal to keep each unit focused on performing only one function, and name each unit based on the function that it performs. This makes it much easier to understand the program, fix it, and enhance it. Remember that you may write the program once, but someone else may have to fix or change it, possibly years later!

Therefore, after using the plan in Figure 6.1, if users returned to you and said that they wanted additional data from the database, you would know exactly what unit to change, and if they wanted the ability to refresh the data, you would know that you can add the ability to call the read data from the database after displaying the data. If you had just one long program, it would be harder to find out exactly where you need to make changes, and you definitely would not be able to reuse any particular unit; the program would all be one long unit.

Of course, each person's interpretation of a unit focused on performing only one function might be different. That's where this concept can become more of an art than a science. If the units are made too small, it can be confusing because there are so many; if they are made too large, it can be confusing because there's so much code in a single unit. Remember that you're both writing a program and trying to make it easy for the next person to fix and enhance.

Naming different units. Figure 6.2 expands on the original conceptual drawing in Figure 6.1 to demonstrate breaking up and naming units for each function that they perform. This example demonstrates a program that gets a list of possible flights based on a search, calculates the price of the flight options, and displays the results to the user. Each unit completes one function, and each unit has a descriptive name. If a person said that there was an issue with the price being calculated, you would know exactly what unit of code he or she was talking about.

Changing units of code. Just because you created certain units of code when the application was created doesn't mean that you can't add more. It's common to have to add additional functionality in a single unit of code, in which case you should determine if the additional functionality might need to be in its own functional unit of code. If each unit is expected to perform one function, ask yourself if the new code is really completing that same function or if it's its own unit. Also, anytime the new code is something that could be reused, then it should be in its own unit.

Once your code is completed and working, it is always good practice to go back and see what kind of improvements you can make to your code and find any code that is repeated and could be modularized.

Now that you understand the concept of separation of concerns, we will cover how to utilize it using object-oriented programming.

Introduction to object-oriented programming

The recommended method for modularizing ABAP programs is to use object-oriented programming. There are some people in the ABAP community who are unsure about object-oriented programming and have even posed the idea that there is ABAP and OO-ABAP (object-oriented ABAP). The fact is that there is no ABAP versus OO-ABAP: just ABAP with good developers and bad developers.

If you have written object-oriented programs in other languages, you will find that there are a few ABAP quirks, but all of the concepts that you have seen in other languages will apply in ABAP as well.

What is an object?

No ABAP programming tutorial would be complete without a discussion about the concept of object. A programming object is designed around the idea of objects in the real world. A good introductory conceptual example is that of a car.

A car has attributes that describe its current state, such as fuel level and current speed, and attributes that describe the object, such as manufacturer and model. There are also a few methods that describe how we interact with the car, such as accelerate, decelerate, and refuel. Figure 6.3 shows a conceptual drawing of this car object.

Each of the object's methods is a functional unit designed to complete one task. Each attribute of the object is a variable that all of the methods have access to. The pseudocode in Listing 6.1 shows what the code in the accelerate method could look like.

METHOD ACCELERATE.
SPEED = SPEED + 5.
ENDMETHOD.
Listing 6.1 Pseudocode of Accelerate Method

Classes. Now, say that the example in Figure 6.3 specifically refers to a Toyota

Tundra, but you want to create additional objects for different types of cars. This is where classes come in. Each object is actually an instantiation of a class, and you can have multiple objects of the same class.

Again think back to the real-life example of a car; the Toyota Tundra is a type of car, and all cars can accelerate, decelerate, and refuel, but this particular car is going at a certain speed and has a certain fuel level. When creating objects, all of the code is stored in the class, but you can create multiple objects that use that code, and each will have its own set of attributes to describe it, as shown conceptually in Figure 6.4. You can think of the class in this example as a mold, whereas the objects are those items created from that mold.

Modularizing with object-oriented programming

Just because you are using object-oriented programming doesn't mean you have to use it to build multiple objects. You could also have one object that holds all of the logic for your program. Each method will represent a single function, as discussed in the section on the separation of concerns principle. Looking back at Figure 6.2, each different unit could be represented as a method in a flight finder class, as shown in Figure 6.5.

Passing data to methods. Each class method can be created with the ability to take and return data. For example, when creating the method for calculating the total price in Figure 6.5, you could pass a value containing the results from the get available flights method.

Structuring classes

Now that you understand some of the concepts of object-oriented programming, you can begin to learn how to create classes and objects in ABAP. If the object-oriented concepts do not make sense yet, perhaps seeing the actual code in action will help. We'll first cover how to create a local class within a program and then how to create a global class that can be used across multiple programs.

Implementation vs. Definition

In ABAP, every class requires a definition and an implementation. The definition lists the different attributes and methods of a class, whereas the implementation contains the actual code for all of the methods. The definition must come before the implementation and must also come before an object is created from the class. The class is defined by using the CLASS keyword, followed by the name of the class and then either DEFINITION or IMPLEMENTATION depending on what you are declaring.

The example in Listing 6.2 contains the definition of a class with no attributes or methods. Prefix the class name with lcl to indicate that it's a local class, meaning that it's being created inside of an ABAP Program. Since we are demonstrating local classes, you can insert the code in this section into any ABAP program for testing. Since both the definition and implementation are contained within a CLASS and ENDCLASS keyword, they do not need to be next to each other when being defined.

CLASS lcl_car DEFINITION.
ENDCLASS.
CLASS lcl_car IMPLEMENTATION.
ENDCLASS.
Listing 6.2 Definition and implementation of a class

Creating Objects

Now that you've created a basic class, you can create objects of that class. Remember that a class is like a design, and you can build multiple objects using that design.

Object variables. There are two parts to creating an object. The first part is to define the object variable. This is just like creating variables, which we introduced in Chapter 2, except that you will use TYPE REF TO instead of just TYPE to indicate the class to be used when creating the object. The example in Listing 6.3 uses the prefix o_ to indicate an object.

For objects, you then use the command CREATE OBJECT followed by the object variable to instantiate the object, as shown in Listing 6.3.

Just like creating your own data types using the TYPES command, the class definition must come before creating an object using that class.

CLASS lcl_car DEFINITION.
ENDCLASS.
DATA: o_car TYPE REF TO lcl_car.
CREATE OBJECT o_car.
CLASS lcl_car IMPLEMENTATION.
ENDCLASS.
Listing 6.3 Creating an object from a class

Public and Private Sections

Before adding attributes and methods to the class definition, you will need to decide whether those attributes and methods should be public, private, or protected. Public attributes and methods can be used within the class or outside Public of the class, from the main program, or even from another class. Private attributes and methods can only be used from within the class Private itself, meaning that another class or the main program is unable to read the attributes or call the methods that are listed as private.

Protected attributes and methods can only be used from within the Protected class itself, just like the private attributes and methods. The difference with protected attributes and methods is that they can be inherited from a subclass, unlike a private attribute or class. We will revisit protected attributes and methods when we cover inheritance later in the chapter.

The public and private sections are defined in the class implementation using the PUBLIC SECTION and PRIVATE SECTION keywords. Listing 6.4 adds those sections to the class definition.

CLASS lcl_car DEFINITION.
PUBLIC SECTION.
PRIVATE SECTION.
ENDCLASS.
ClASS lcl_car IMPLEMENTATION.
ENDCLASS.
Listing 6.4 Adding the public and private sections to the class definition

Next, you can add attributes to public or private sections, by creating Attributes variables, just like the ones discussed in Chapter 2. The variables must be defined after a section to determine whether they're public or private.

These attributes will be available globally to all of your methods; if they're public, they'll also be available globally outside of your methods. Listing 6.5 adds public attributes for fuel, speed, brand, and manufacturer and a private attribute for the current gear.

Read Only attributes. Public attributes can also be given a READ-ONLY property, which will make them readable outside of the class and changeable only from within the class. In Listing 6.5, the attribute d_manufacturer is set to be read-only.

CLASS lcl_car DEFINITION.
PUBLIC SECTION.
DATA: d_fuel TYPE i,
d_speed TYPE i,
d_brand TYPE string,
d_manufacturer TYPE string READ-ONLY.
PRIVATE SECTION.
DATA: d_gear TYPE i.
ENDCLASS.
ClASS lcl_car IMPLEMENTATION.
ENDCLASS.
Listing 6.5 Adding public and private attributes to the car class

For more of this SAP ABAP programming tutorial, download the chapter.
The excerpt from Getting Started with ABAP by Brian O'Neill is reprinted here with the publisher's permission.
© 2016 by Rheinwerk Publishing, Inc. Getting Started with ABAP / Brian O’Neill. ISBN 978-1-4932-1242-2. 

About the author:
Brian O’Neill is an ABAP developer with 10 years of experience working across different SAP ERP modules and custom applications. Currently, Brian is focused on mobilizing SAP environments as an SAP mobility senior consultant with IBM. He has been a speaker at multiple SAP technology conferences, including Mastering SAP Technologies and SAP TechEd. Brian was also featured in the 2011 Demo Jam at SAP TechEd in Las Vegas.