ABAP OO: 5 Rules of Thumb for Access Modifiers
ABAP OO requires in its object oriented programming style the assignment of the methods and attributes to the class section (a.k.a. access modifiers) private, protected and public (explained for Java). This programming language is often enhanced at customer projects to accommodate customer specific requirements. Hence, the usage of those access modifier in the standard coding is having a considerable impact on the time those customer enhancements need to be implemented as well as the time they need to be maintained.
I have noticed that the access modifiers private or protected are used in several cases where a less restrictive access modifier would have kept the possibility to reuse more standard coding and reduced the required additional custom code. Therefore, I will provide 5 rules of thumb and hope to start a discussion leading to a more relaxed use of the access modifiers.
 |
PRIVATE Attribute/Method: |
- If no subclass exists, never use it!
- If in question, use protected instead.
- Private methods do only make sense if they access private attributes.
 |
PROTECTED Attribute/Method: |
- Access modifier of choice if other classes should be prevented from changing the attribute directly or calling the method.
 |
PUBLIC Attribute/Method: |
- Access modifier of choice if other classes cannot do any harm by or should be allowed to change the attribute directly or call the method.
Following those rules will provide also guidance on how to encapsulate coding even when no subclass exists at the moment. For example, modifying private attributes should be done in a private method most of the time.
If you wonder why this is important? Let’s look at the following example:
None of the attributes should be private:
The first three attributes start with the prefix ‘GC_’ and are private constants. The naming convention states that the first letter ‘G’ is used to indicate the global usage of this constant, so already at that point it is obvious that there is something wrong with the access modifier being private. Another hint would be rule 1. and the fact that this class has no subclass. Furthermore, since the nature of constants is that they cannot be modified access cannot do any harm so rule 5. applies and those attributes should be public.
The last attribute IO_TOR_SRVMGR is an attribute that is initialized in the redefined method FILL_PRINTSTRUCTURE and the other methods only use read access to that attribute. This also indicates that the usage of the access modifier private is too restrictive. I would suggest to use protected instead especially when thinking about possible subclasses. This change would enable them to also use the read access when redefining one of the other methods.
Hi Erik,
thanks for bringing up the topic of access modifiers and inheritance. However, I have to say I strongly disagree with you rules of thumb. IMHO they are misleading at best. Regarding a private attribute/ method you state the following:
Both statements are simply wrong in my opinion. How is having no subclass related to the attribute visibility? Using public or protected for attributes encourages accessing the attributes of a class directly instead of using the methods to do so. Access restrictions for methods and attributes are related to the discussion to only accessing and modifying attributes of a class by using the appropriate method or even the discussion of mutable vs. immutable objects. Simply saying never use private isn't correct and only encourages bad design.
Regarding protected attributes or methods you state:
Again this is simply wrong. Protected is the access modifier of choice if you want to allow subclasses to access a method or attribute. This is, for example necessary if you want to design a framework where you provide a default implementation but want to allow users to the framework to change some functionality using subclasses. Even in this case using composition over inheritance is usually the better decision. Therefore protected is the correct access modifier only in very few cases.
Regarding you example. Isn't it enough to overwrite one of the visible methods? Why do you want to access IO_TOR_SRVMGR? I'm not saying there is no reason to access this attribute but maybe there is better object-oriented approach to implement you requirement. Just saying this attribute should be protected or public isn't the right approach.
For me the one rule of thumb you should add to your list is: Only make a class final if you want to make sure no subclasses can be created.
Best,
Christian
Hi Christian,
Thank you for getting the discussion started.
I would fully agree with you if the whole design would be always thought through very well and the programming language would be Java or C++.
However, ABAP OO is used by SAP for developing standard software which is often extended by SAP or enhanced at the customer side and those enhancements are getting more complicated when more restrictive access modifiers are used.
IF an attribute should really be handled only in its class then also if no subclass exists private should be chosen. This follows directly from the definition of this access modifier which I do not want to change, but rather encourage to follow more accurately. Then rule 1 would be wrong.
BUT in many cases of design that I have seen so far in standard SAP coding there is no requirement for restricting attributes to only private access, especially on the leaf-level or a class hierarchy. As those classes are mostly extended in customer projects for me the rule would be to use protected rather than private when in question.
Nevertheless, I agree that rule 4 is a little too imprecise. With "other classes" I meant classes not being the class itself or its subclasses. Also here I do not want to contradict the definition of the access modifier.
Furthermore, the extensive use of tables in ABAP OO makes the encapsulation such table attributes a possible performance problem. They would have to be copied every time another class wants to access them. I guess for that reason those getter-methods don't even exist (again: as far as I have seen it).
Concerning the attribute IO_TOR_SRVMGR (which is a reference to an object instance) I suggested an easier adaption then a redesign with additional coding. In a perfect object-oriented world this attribute could also be private and have a getter-method which uses a version of the singelton pattern checking whether the reference is initial and returning either the existing reference or on that is created new.
I would very much appreciate if that would have been the way the class was build. In reality I must admit that this almost never happens and the easiest way to change the existing coding so it can be at least extended easily is to change to access modifier to protected.
In any case, if the design is nicely put in an object-oriented way. The rules of thumb from above can be disregarded. My target-group is the developer have to decide on that in a second and usually not having time to come up with a nice OO design for new coding or redesign the current coding in an OO way.
Best regards,
Erik
Hi Erik,
I don't fully agree with what you have written. I strongly believe that the access modifiers used shall be a decision on the design time of the functionality:
If an attribute or method is a implementation details that only the class should know, then it is of course a private attribute or method.
If an attribute or method should not be accessible by other classes other than itself and its sub classes, then of course it must be protected.
If an attribute or method shall be accessible by other classes it shall be made as public.
If the architect/developer of the standard software plans a functionality to be extensible it shall use a template method (or other mechanism) so others can extend the functionality. Also, standard software usually includes enhancements spots or BadIs for extensions.
What I am trying to say is that "relaxing the rules" for access modifiers can give a wrong understanding of the intent. Also, the developers from the standard can later decide to change a "protected method", how do you ensure that it continues to work with the extended version? What if the method gets deleted? The idea of private means that it is a implementation detail therefore you should not rely on it.
What I think it must be done is to conform to the Open/Closed Principle when developing Standard Software and leave clear extension points were it applies. I believe that software requires no rules of thumb but a clear analysis of each case.
Best regards,
Pietro
Thank you Pietro for your reply.
I see your point and I very much like the idea of SAP providing many enhancement possibilities, but in reality most customers I have seen were asking for many changes outside of BAdIs and template methods. This might be due to the market area I am working in, but also in other areas I do not see the point why a customer project should rather copy many lines of standard code because of unnecessary restrictive use of the access modifiers than reusing existing code.
Also developers/architects usually do not have the time to check for every reuse possibility, so the rules of thumb from above were meant as guidance in case of uncertainty.
Best regards,
Erik
Erik, I think that SAP developers won't follow any of your rules at all.
Imagine about how many Support Tickets would be opened if this "relaxed" system architecture wouldn't prevent people from enhancing standard code whenever they wanted to...
I know that you're trying to ask SAP developers to make things more simple to reuse, so our ABAP lifes are a little bit easier, but I just don't see how such thing could work in the real business-world.
Hi Mauricio,
Customers always open customer messages also for problems coming from their own enhancements or customizing errors. I do not see why this should increase by the rules of thumb. Problems occurring from reuse will still have Z* names in the method trace pointing to an enhancement problem.
Furthermore, SAP is - at least in my understanding - anyway only reliable for the standard code to work in case it is used within the standard context. So if a customer message is opened due to a misuse by an enhancement SAP could push back the message with that argument.
Best regards,
Erik