A lot is written and explained on the class instance, instantiating a class or the difference between classes and objects. An object is an instance of a class. Let me lead you to a simple example that demonstrates this. Imagine: cars in a carpark.
Cars in carparks
Somewhere in Classy-city there is a street with 2 carparks. They are called North and South, because of the way the car parks are situated. We are going to develop a little Abap that manages cars in both carparks. The (an) Object Oriented way to do this is to define a class lcl_car and another one that is called lcl_parking. The lcl_ is the naming convention for local class.
First we will define the car. It's life will start when it enters the carpark and en again when it leaves. We define the class for the car with the following attributes (properties, variables).
CLASS lcl_car DEFINITION.
PUBLIC SECTION.
DATA:
gv_licenceplate type string,
gv_timestamp_in type timestamp,
gv_timestamp_out type timestamp.
ENDCLASS.
The PUBLIC SECTION. defines the "visibility" or "accessibility" of whatever is listed in the public section block. Public means available to everyone from anywhere. The DATA definition is an interesting one, when compared to the CLASS-DATA definition. A regular DATA definition defines object attributes where as the CLASS-DATA definition defines class attributes (global variables). With the definition above, we have declared the definition of a car, without any methods.
Use a class without methods?
A class does not have to have methods. It can be used like a data container for a car, as the logic below demonstrates:
DATA: go_myCar type ref to lcl_car. create object go_myCar. go_myCar->gv_licenceplate = '89KVV6'.
Objects need to be created, hence the CREATE OBJECT call. As the example has no CONSTRUCTOR, the CREATE OBJECT statement does not process any parameters. Have you noticed the -> ? If you are wondering why it didn't state => instead: it's good to know that the -> is used for object references and the => is used for class references.
A carpark
So now that we have defined a car, let's also define a carpark. What is important to realize at this point is the fact that we need 2 carparks, representing the North and South side of the street. Hence carpark information is also object information. The setup, this time with some methods includes the following information. For a visiting car, the start and end times of a visit are logged. The licenceplate of the car is also logged. Methods to create a carpark and allow a visiting car to drive in and drive out are included:
CLASS lcl_carpark DEFINITION.
PUBLIC SECTION.
TYPES: begin of ty_visiting_car,
car type ref to lcl_car,
gv_timestamp_in type timestamp,
gv_timestamp_out type timestamp,
end of ty_visiting_car.
DATA:
gv_name type string,
gt_visits type standard table of ty_visiting_car.
METHODS:
constructor importing carparkname type string,
drive_in importing licenceplate type string,
drive_out importing licenceplate type string.
ENDCLASS.
A carpark with methods also needs an IMPLEMENTATION of the class. The example below only has it's CONSTRUCTOR filled in (for now):
CLASS lcl_carpark IMPLEMENTATION.
method constructor.
gv_name = carparkname.
endmethod.
method drive_in.
endmethod.
method drive_out.
endmethod.
ENDCLASS.
Note the relationship between carpark and car: a carpark has a table with visiting cars, which is a single list for the whole carpark. Each entry of this list contains a car and for each entry on the GT_CARS table there is a reference to LCL_CAR.
Live action
Let's put some cars into the carpark. For this the START-OF-SELECTION event is needed (otherwise the coding would contian unreachable code).
start-of-selection.
data: lo_north type ref to lcl_carpark,
lo_south type ref to lcl_carpark.
* Create the carparks:
create object lo_north
exporting carparkname = 'Class-city Carpark - North'.
create object lo_south
exporting carparkname = 'Class-city Carpark - South'.
* Bring a few cars to the parks:
lo_north->drive_in( '89-KVV-6' ).
lo_north->drive_in( '52-RK-DF' ).
lo_south->drive_in( 'R1243AL' ).
So the above coding describes 3 cars that are using the carparks. 2 of them at the North end, one in the South carpark. However, the methods in DRIVE_IN (and DRIVE_OUT) are not actually filled in (no coding). So what should be done in the drive in method ? The visit of the car should be registered. An entry on the GT_CARS table should be created, for which the start time can be filled in. Coding for the DRIVE_IN method:
method drive_in.
data: lw_visiting_car type ty_visiting_car.
clear lw_visiting_car.
create object lw_visiting_car-car.
lw_visiting_car-car->gv_licenceplate = licenceplate.
GET TIME STAMP FIELD lw_visiting_car-gv_timestamp_in.
append lw_visiting_car to gt_visits.
endmethod.
First of all the car object is created, after which the licenceplate is set. Then the timestamp is set to the current date and time. To conclude the drive in action, the administration is saved in the GT_CARS table.
Leaving the carpark
Our customer has high expectations, so we will have to allow drivers to take their cars out of the carpark sometimes. The timestamp of the end of the visit will need to be logged, which is done in method DRIVE_OUT as shown here:
method drive_out.
field-symbols: <visiting_car> type ty_visiting_car.
read table gt_visits assigning <visiting_car>
with key car->gv_licenceplate = licenceplate.
if sy-subrc = 0.
GET TIME STAMP FIELD <visiting_car>-gv_timestamp_out.
endif.
endmethod.
The assigning bit is just an easy way to apply changes to an entry in the loop, nothing Object Oriented about it. So the car leaving the compound is looked up, and the time it's leaving is noted. Looks OK to you ? There's a serious error in it. Take a moment to see what it is.
Found it ? Here's a hint: cars can return to the carpark.
Assuming the car can visit multiple times, the administration on GT_CARS should be processed a little differently. It's really GT_CAR_VISITS, but we'll hang on to the old name. With some corrections:
method drive_out.
field-symbols: <visiting_car> type ty_visiting_car.
read table gt_visits assigning <visiting_car>
with key car->gv_licenceplate = licenceplate
car->gv_timestamp_out = 0.
if sy-subrc = 0.
GET TIME STAMP FIELD <visiting_car>-gv_timestamp_out.
endif.
endmethod.
So if a car enters our Norhtern carpark, then leaves again to go to the Southern carpark to return in the Northern carpark again, the individual car park visits will be logged on the individual objects of North and South carparks (lo_north and lo_south). Now this is just a simple example and the effect may not have sunk in yet, but this is the absolute greatest thing in development language world. Homeless globally defined attributes find a place to live, a place where they belong, with controllable boundaries as to where they can go.
Car registry
The owner of the carparks has decided to keep a record of individual cars. Whichever car visits one of the carparks - the car will be registred in a car-registry. As this is not related to either carpark, the registry is set up on LCL_CAR. Check out the example below, where a few things are added to the example described in this article. There is a TIME_REPORT method that reports the activity on the carpark. There's also a car registration on LCL_CAR. Try to visualize how real objects like cars and carparks relate to the Abap Object Oriented version of these very (no really: very) same objects.
Having cars enter and leave a carpark is an example with real life objects, which is what Object Oriented programming in essence is about. It's no longer a listing of routines and variables with which a real life situation is composed, Object Oriented starts with the actual real life objects.A car or a carpark. In the example source code below another real life object was introduced: the clock. The idea there is that when a simulation of driving cars is prepared, we should be able to put thesa actions on a timeline. Class lcl_timeline has only 1 method: read_clock which will add a random number of seconds to the clock and return the new "next time". Try this coding on your system, a full simulation report demonstrating objects in just over 200 lines of coding.
.
Some of your questions...
Why was lcl_timeline introduced as a new class ? Just for a single method ?
The timeline class is a very stand-alone matter, if it was to be made part of the other objects, car or carpark, it would belong on the carpark. You can imagine that the clocks in different carparks don't show the exact same time, which would be a good reason to make a timeline object (instead of a timeline class) part of the carpark. Alternatively the timeline object could be made part of the carpark class (not the carpark object). Yet in the grand scheme of things, the timeline would be a valid class even without carparks.
How do you name a class
Class names are important. Pick a wrong name and you will confuse the h..l out of fellow developers and even yourself. Stick to the lcl_ convention and change the class name when you think of a better one. You will be surprised how little impact a class name change has and what the value of a well chosen class name is.
Why cars and carparks ?
It shows the use of actual real life objects that we all know. Wa also know the Purchase Order and the Invoice, but a lot of prior knowledge about these documents will make it more difficult to understand the Object Oriented class and object concept.
Car registry - class and object in one ?
The car class has a table of cars as well as a car object. It demonstrates that class attributes and instance attributes (object variables) can live a very happy life together.