Copyright 2021 - BV TallVision IT

In Object Oriented - visibility is an important feature, which should be used and ulitized to the fullest. So what is visibility ? What does it mean - something is visible, or not. What something ? Visibility applies to both attributes (variables) and methods (procedures, routines). The developer of a class can thus decide whether certain attributes are available to the "outside world", and which of his/her attributes are used in the internal bowels of the class (or classes) only.

Defining visibility is done in a definition phase and visibility can not be changed at runtime. Private, protected and public are the available visibility levels, which is not only an Abap-thing (PHP, Java, many others). In summary, your attributes or methods are defined in one of these sections: 

  • Public Section

    All of the components declared in the public section are accessible to all users of the class, and to the methods of the class and any classes that inherit from it. The public components of the class form the interface between the class and its users.

  • Protected Section

    All of the components declared in the protected section are accessible to all methods of the class and of classes that inherit from it.

  • Private Section

    Components that you declare in the private section are only visible in the methods of the same class.

So how does this work with attributes in practice ? 

The class you are developing can have "global attributes" which can be accessed from all the methods of the class. In fact, visibility of these attributes is no issue for methods in a class, as all is allways visible - from within the same class. But of course a class is set up as something with a higher purpose: it can be called from other classes. As a developer you get to decide what attributes can be accessed. A short example: you have a class for a CD collection which holds both CD's as well as songs per CD:

*       CLASS lcl_flights DEFINITION

    DATA gt_flights TYPE STANDARD TABLE OF sflight.
    METHODS constructor.

    DATA gt_schedule TYPE STANDARD TABLE OF spfli.


So in the above example, the class has 2 table attributes. One is Public, one is Private. The Public attribute can be accessed from outside the class, the Private attribute (flight schedules) are only available from within the class. The constructor will take care of data selection when the object (instance of the class) is created. For completeness, the CONSTRUCTOR:

*       CLASS lcl_flights IMPLEMENTATION

  METHOD constructor.
    SELECT * FROM sflight INTO TABLE gt_flights.
    SELECT * FROM spfli INTO TABLE gt_schedule.


To use the above class, it needs to be instantiated first, here's a simple example:

DATA: go_flights TYPE REF TO lcl_flights.

  CREATE OBJECT go_flights.  

When the class is instantiated, GO_FLIGHTS holds the class instance with it's content: 2 internal tables (all supplied with values). Accessible like so:

  read table go_flights->gt_flights index 3 into lw_flight. 

If you try the same for the schedule lines table attribute, you will get a compiler error:

read table go_flights->gt_schedule index 2 into lw_schedule. 

The error:

Access to private attribute "GT_SCHEDULE" is not allowed.

The whole idea behind this is data encapsulation: there is no need to know all ins and outs of every class, classes can be composed as black boxes which can be used without having to "peek inside". The fact that a private attribute is not available to you is in fact very valuable information: it explains you don't have access to the information directly, probably for very good reasons. Maybe there are methods available to gain access to the information, or maybe the information is not reliable - if it was available. The class is not just designed to perform a task, the actual use of the class is also designed.