In object oriented programming, any object has to be defined, implemented and instantiated before it can actually be used (except static objects that don’t need to be instantiated).
To define correctly an object in object oriented ABAP, it is necessary to understand first what an object really is according to the object oriented programming paradigm.
We have seen in our introduction to ABAP Objects that the concept of object is at the heart of this programming technique. An object may represent any concept that a program may need to manipulate to achieve its objectives. It represents a self-contained, functionally meaningful logical entity. Objects are the key organizational element of programs in object oriented programming. They constitute the driver for a functional organization of the programs instead of their technical organization.
Objects contain both source code (defining the functionalities of the objects) and attributes (defining the specificities of the objects).
Organizationally speaking, this combination of source code and variables within logical units is a major enhancement compared to the classical procedural programming technique where the source code is arranged in procedures and the data is largely independent of the source code. With the object oriented programming the source code and its related data is encaspulated in objects that form autonomous logical entities that create a functional link between the source code and the attributes that become at the same time highly dependent from each other and isolated from the other functional units of the program.
The objects defined in a program (or more generally in a system) usually make sense only in the context (the world) of that program. This is because the program has specific objectives and defines the objects it requires with only the properties and methods necessary to achieve these objectives.
Let’s take an example. As we are in the world of computer sciences, let’s consider an object we all know very well: the computer. The computer is a concrete object (you are certainly facing one if you have not printed this article) but it is also a concept because you can certainly imagine computers of many types (desktop, laptop, servers, …) with many different configurations. But still they are all computers because they all share the same intrinsec characteristics and functions which make YOU consider them as computers.
The definition that you give to a computer (consciously or not) may be shared by other individuals but not necessarily. This definition is based on characteristics and functions that the object computer must have to be considered as such and may vary from one individual to another. Someone may consider that game consoles, calculators, cellular phones and similar devices are computers as well because their definition of computers is based on characteristics and functions that these devices have (electronic parts, keys and a screen for example). Someone else could say he doesn’t agree because these devices are not able to run his preferred word processing software or are maybe not powerful enough.
Just like the defintions of objects in the real world are specific to individuals, the definitions of objects in object oriented programming are specific to programs (or systems). And an object definition makes sense only in a specific context.
Note however that this context does not necessarily need to be very specific. Some very generic contexts may be considered as well which leads to generic object definitions which apply to many situations but usually require some refinement when things get more concrete (that’s the purpose of the object inheritence).
A class is a definition, a prototype of an object. It is used to define objects but it is not an object by itself. An object is nothing else than an instance of a class (we will come back to this point in a next article about object instantiation). A class may have many instances and thus many objects may be created based on one single class.
A class definition indicates what will be the properties and functions that will characterize the objects that will be created using this class. It consequently creates a tight link between the properties (data) and methods (functions) it defines. It also specifies the interactions that these objects will support by defining events.
Let’s consider a minimal class that could be used to define business partners at a very general level. We consider here that a business partner is any logical entity that has a name and a tax identification number.
CLASS LCL_BUSINESS_PARTNER DEFINITION.
PUBLIC SECTION.
METHODS:
m_SetName IMPORTING Name TYPE STRING,
m_GetName RETURNING VALUE(Name) TYPE STRING,
m_SetTAX IMPORTING VAT TYPE STRING,
m_GetTAX RETURNING VALUE(VAT) TYPE STRING.
PRIVATE SECTION.
DATA:
m_dSName TYPE STRING,
m_dSTAX TYPE STRING.
ENDCLASS.
This class defines two attributes (the business partner name and its TAX registration code which can be a VAT code for example) and four methods used to set and get the object attributes. These are necessary because the attributes are defined in a PRIVATE visibility section.
The visibility sections in a class restrict the access to the class members. More precisely they define who has access to the different members of the class.
There exist three visibility sections:
The public section defines properties and methods that may be accessed from anywhere. This section makes no restrictions on the access to its members.
The protected section contains members that may be accessed only by the object to which they belong or an object derived from that object (one of its child objects). This section is used in conjunction with inheritence, which we will see later when we will derive classes.
The private section gives no access to the members it declares except to the methods belonging to the object itself. It means that these members may be accessed only by the objects to which they belong. No external code can access these members.
Although there exist three visibility sections there is no obligation to have them all declared in all classes. However there is an obligation to declare them in a specific order from the most visible one to the least visible one (i.e. the public section first followed by the protected section and finally the private section).
A class may contain properties (data), methods and events. We will now see the properties and the methods and we will leave events aside for the moment as a specific article is devoted to them.
The class data define the attributes of the objects and are declared just like normal variables (taking into account the more restrictive syntax check that applies when programming with object oriented ABAP) .
Class methods define the functionalities of the objects and are declared with a syntax similar to that of classical subroutines (FORMs).
In the next article we will see the object implementation phase which consists in actually implementing the functionalities (the methods) of the objects.