Skip to Content

I’ve recently been spending a lot of my time coding in ruby, where the rules for private and protected methods are different to how they are in C++ (and ABAP). I would say that ruby is more ‘relaxed’ and people don’t often make something private in ruby as part of usual practise. In ruby accessors do behave differently by design, and this difference is well described by this quote from Lovable Lyle, “…in C++, “private” means “private to this class”, while in Ruby it means “private to this instance”.” ABAP is like C++ in this regard.

In ABAP, especially for developers who don’t work for SAP, PRIVATE methods and attributes in SAP standard code often are a source of difficulties.

Here is an example that I’d like to explore, taken from a CRM system:
Example of problematic private attributes

Especially note the private attributes for constants. One almost could anthropomorhphize things, and say SAP must be really scared that I would want to change the values of those constants in child classes. That’s why they must be private!

I would make the argument that declaring these attributes protected would provide the best of both worlds, it wouldn’t stop usage by child classes, and would provide the encapsulation desired.

The example above is for a CRM controller. Such controller classes often have child classes, because when one enhances a view of a component, the system will automatically create a Z-controller (in my case it created ZL_CRMCMP_I_HIDDENVIEW_IMPL) which inherits from the parent controller.

For the example, I needed to use the CODE_MESSAGE constant (‘AbapErrorMessage’) in my custom logic so that it behaved similary to SAP standard. These were the choices I could think of, all of which have drawbacks:

  • Enhance the parent class to make it a friend of the child
  • Enhance the parent class to provide a protected or public accessor method for the attributes required
  • Modify the parent class to make the attribute public
  • Create an enhancement spot in the parent method, and insert the custom logic that I want there
  • Make my code not behave like SAP standard
  • Make my own local constant

I tend to avoid SAP standard code enhancements. Especially enhancements that are static. Such as making the parent a friend specifically of ZL_CRMCMP_I_HIDDENVIEW_IMPL, as this name might change if a new enhancement set were to be created.

It seems to me therefore that the latter option (“make my own local constant”), is the superior choice. The major worry with this approach is that if SAP had to change the value of the attribute in a future release to something like ‘AbapNewErrorMessage’  my code would silently break in a way that would be difficult to detect. If the parent attribute wasn’t private, but public, and could be referred to directly there would have been no concerns about upgrade changes causing breakage.

Now, one could make the argument that my example chosen has been cherry picked. Unfortunately, this is something that I have encountered many times, most commonly with the visiblity of methods rather than attributes.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Sandra Rossi
    Thanks for sharing your experience.
    Gee, I thought ABAP was using “private to the instance”. Thank you for correcting me.
    One thing I don’t understand is why you think duplicating the constant is “the superior choice”. Could you develop? According to me, your “major worry” could be sufficient to choose the enhancement framework. Okay, it is not really beautiful, but it takes only 2 minutes, so what’s the trouble with that?
    (0) 
    1. Jonathan Groll Post author
      Yes, you’re quite correct, enhancement spots make it much easier to enhance standard code nowadays. They’re just difficult to find when later developers look at the same code (from reading code in the Z- child-classes another developer won’t know at first that you needed to enhance something in the standard code of the parent class). Use of enhancement spots may also require some minor manual work during a system upgrade (via SPAU_ENH).

      It is also important to clarify what is meant by the “enhancement framework”. CRM component enhancement is automated by the CRM framework and involves the system automatically creating a Z-BSP and Z-child classes where developers extend the system by developing custom or redefined methods. This is not the same as enhancement spots as referred to above and in the blog post.

      (0) 

Leave a Reply