Skip to Content
Author's profile photo Gerd Rother

Private and Public Read-Only Attributes

In blog entry How to set up your ABAP Objects Classes Timo John pointed out the advantages of using public read-only attributes against private attributes with a “getter” method.

While I generally agree with him I want to point out two aspects you should consider as well when designing your classes in ABAP.


As Timo already pointed out you can save some coding and memory by using public read-only attributes. But what about performance? To answer this question I wrote a small class and a test program.



A method within this class returns the private attribute’s value:

method get_private.

private = me->private.


To compare the performance I wrote a small program which gets both values and doing something with them (here: writing it to another field).

To have some time to measure this is done in a loop:

program ytestq.

parameters: times type i default 1000.

data: testobject type ref to ycl_test,
      start(16) type p,
      end(16) type p,
      private(16) type p,
      public(16) type p,
      ratio(16) type p decimals 2,
      my_value type char10,
      out type char10.


create object testobject.
get run time field start.
do times times.
        my_value = testobject->get_private( ).
        write my_value to out.
get run time field end.
private = end - start.
write: / 'private:', private.
get run time field start.
do times times.
        write testobject->public to out.
get run time field end.
public = end - start.
write: / 'public:', public.
ratio = private / public.
write: / 'ratio', ratio.

Running the program it shows that using the public attribute is about 4-5 times faster than using the private attribute.

Information hiding

Making an attribute public read-only seems to be quite save – yet it still violates the principles of information hiding.

An example:

In our program we show a field in a screen which is currently stored in a database table. We created a class which represents the entity of the business object the table is actually storing.

To make the access to the object’s attributes easier we defined that field in the class as public read-only. From the screen program we simply directly access that attribute to populate the corresponding field in the screen.

After some time there is a requirement to not store that field in the database table but to compute it by values, which may change during the transaction and are changed from outside (e. g. by other users in other database tables).

While our class could compute this value at object instanciation we only have the first value on the screen which will never change unless we compute the value again.

So we have to change the screen program in order to call another method which computes the current value of the field. But why should we do this? Essentially the screen program needs no change – its logic was not changed at all. Everything what was changed is the internal logic of that business object.

If we made the field private (or protected) we simply had to change the getter method which automatically re-computes the value. Hence the probability of side effects is much lower than in the solution above.

You can imagine there are cases where the effort for program changes not using private members is much higher than in this example.


I suggest to use public read-only attributes only if you are pretty sure its internal representation will not change. Otherwise future change requests might lead to higher effort in designing, programming and, last but not least, testing.

But if you are sure about that do not hesitate to use public read-only attributes for the advantages (esp. performance) are convincing.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      I think it's a bit misleading to talk about performance improvements when comparing usage of accessor methods versus direct reference of public attributes. You only talk about timing ratios, but when you look at absolute numbers the differences seem negligible (and I mean in real world applications, not overly simple test rigs).
      Of course even the published ratios will vary by machine/system. E.g. I got a ratio of 3 and once I added the missing extra assignment to your public test loop (using my_value, which should be there to have a fair comparison) it came down to 2.4... 😉

      Anyhow, the one aspect that I often miss in those discussions is the beloved KISS principle. An additional getter method for a private read-only field is code-bloat due to missing language features (i.e. first class language properties).
      Thus I'm wondering how many people have encountered problems like this in their career and how often? (Seems more relevant to me when we talk about changes to public fields.)
      It would be great if you and others could share their experience broaden my horizon...

      Cheers, harald

      Author's profile photo Gerd Rother
      Gerd Rother
      Blog Post Author
      Hi Harald,

      Thank you for your reply.

      I think it is always worth spending some thoughts about performance when you write a piece of code. Of course, the time you win using public attributes (vs. using private ones) might by negligible compared to some big SELECT you perform in the same application. In my time as a consultant I met many developers never considering the performance of the code and wondering why their applications were that slow. So I wanted to point out that there is a difference (like using loop into vs. loop assigning).

      And yes, the way ABAP is designed does not make it simple using access methods - all I wanted to do is to point out that using public attributes (even read only ones) violates information hiding.
      I actually came across situations where a private attribute would have make changes easier than the public attribute which was existing in a class. But to be honest, I very often use public read-only attributes. Here, again, you have to use your experience and instinct to find a pragmatic solution.

      Cheers, Gerd