Before you can begin to grasp OO-related concepts such as inheritance or polymorphism, you must first understand the fundamental concepts of classes and objects. This article will introduce you to these ideas.
Why do we need classes?
With all of the robust data object types available in the ABAP programming language, you might wonder why we even need classes in the first place. After all, isn't a class just a fancy way of defining a structure or function group? This limiting view has caused many developers to think twice about bothering with OO development. As you will see, there are certain similarities between classes and structured data types, function groups, etc. However, the primary difference with classes centers around the quality of abstraction. Classes group data and related behavior(s) together in a convenient package that is intuitive and easy to use. This intuitiveness comes from the fact that classes are modeled based on real-world phenomena. Thus, you can define solutions to a problem in terms of that problem's domain - more on this in a moment.
Classes and Objects: Defined
Over the years, the term class has been adopted by most OO languages to describe the concept of an abstract type. Here, the use of the word "class" suggests that developers are surveying the problem domain and "classifying" objects within that environment. For example, when developing a financial system, it stands to reason that you might identify classes to represent accounts, customers, vendors, etc. Generally speaking, any noun in a functional specification could suggest a particular object. Of course, it is important to remember that a noun describes a person, place, thing, or idea. In the financial example above, it is easy to identify things like accounts, etc. However, an abstract concept like a dunning process is an equally good candidate for a class.
You can think of a class as a type of blueprint for modeling some concept that you are simulating in a problem domain. Inside this blueprint, you specify two things: attributes and behaviors. An attribute describes certain characteristics of the concept modeled by the class. For instance, if you were creating a "Car" class, that class might have attributes such as "make", "model", "color", etc. Technically, attributes are implemented using various data objects (e.g. strings, integers, structures, other objects, etc.). The behavior of the class is defined using methods. The "Car" class described earlier might define methods such as "drive( )", "turn( )", and "stop( )" to pattern actions that can be performed on a car. The figure below shows an example of the class "Car" with some basic attributes and methods.
The "Car" class described above only defines a blueprint for building a car - and not the car itself. Taking the blueprint metaphor a step further, consider the difference between a set of blueprints for a house and a house that is built in reference to those blueprints. The blueprints for a house describe basic dimensions, layouts, etc. In other words, they provide instructions for building a house. A homebuilder takes these specifications and builds an instance of this house. An instance of a house has a unique physical address and can be customized to suit a persons preferences. In OO-parlance, an instance of a class is called an object. The relationship between a class and object instances of that class is shown in the figure below.
Defining Classes in ABAP Objects
Now that you know what a class is, let's look at how to define one using ABAP syntax. In ABAP, a class is developed in two parts: a definition section and an implementation section. The definition section for the "Car" class described above looks like this:
CLASS lcl_car DEFINITION.
PUBLIC SECTION.
METHODS:
drive IMPORTING im_driving_speed TYPE i,
turn IMPORTING im_direction TYPE c,
stop.
PRIVATE SECTION.
DATA:
make TYPE string,
model TYPE string,
color TYPE string,
driving_speed TYPE i.
ENDCLASS.
In my next blog, we'll go into more details about the PUBLIC SECTION and PRIVATE SECTION specifiers you see in the class definition. For now, it is enough to simply note that we have defined a class called lcl_car that contains methods and attributes. As you can see, attributes are defined using the same data types you would use to define a global or local variable in a non-OO context. Similarly, methods can be defined to have various parameter types just like form routines or function modules.
Presently, our lcl_car class does not have any implementation for the methods drive( ), turn( ), and stop( ). These methods must be implemented in the implementation section of a class definition. The syntax for the implementation section is shown below:
CLASS lcl_car IMPLEMENTATION.
METHOD drive.
driving_speed = im_driving_speed.
WRITE: / 'Current speed is:', driving_speed.
ENDMETHOD.
METHOD turn.
IF im_direction EQ 'L'.
WRITE: / 'Turning left...'.
ELSE.
WRITE: / 'Turning right...'.
ENDIF.
ENDMETHOD.
METHOD stop.
driving_speed = 0.
WRITE: / 'Stopped.'.
ENDMETHOD.
ENDCLASS.
Now that our class is fully defined, we will do something useful with it in the next section.
Instantiating and Using Objects
Once a class is defined, you can create instances of that class in your programs. ABAP does a really nice job of abstracting the instantiation process so creating an object is a breeze. However, the abstraction process implies that you do not have direct access to an object at runtime. Rather, you work with objects via an object reference variable that points to the object. Object reference variables are defined like this:
DATA: lr_car TYPE REF TO lcl_car.
The previous syntax defines an object reference variable called "lr_car" that references objects of type "lcl_car". Once the reference variable is defined, you can create an object using the following syntax:
CREATE OBJECT lr_car.
The CREATE OBJECT statement asks the ABAP runtime environment to build an object of type lcl_car and store a reference to that dynamically generated object inside the reference variable lr_car. You can think of this reference variable kind of like a remote control that can be used to interface with the object it points to. To "press buttons" on this remote control (i.e. access data, call methods, etc.), you use the object component selector (or "->") operator. The example code below shows how to invoke methods on a generated car object:
lr_car->drive( 55 ).
lr_car->turn( 'R' ).
lr_car->stop( ).
As you can see, onenice thing about objects is that they are really easy to use. Therefore, you don't have to be an OO guru to start using some really handy classes in your programs. Indeed, if you search for classes matching the pattern "CL_ABAP*" in transaction SE24, you will find many useful classes that SAP has provided out of the box with the AS ABAP.
Summary
Hopefully by now you have learned how to create simple classes and use them in your programs. In my next blog, I will show you how to use access specifiers to implement encapsulation and data hiding in your classes.
11 Comments
