Skip to Content
Technical Articles

Way to achieve clean design in ABAP Classes !!

Very often I am approached by developers, technical consultants and SAP enthusiast with the following question.

“What is the optimal way of writing code in ABAP? Is there any model or principle that should be followed?”

Well today I will take the opportunity to explain a few aspects of Clean Design that should be followed while coding in ABAP, or rather one should adhere to while coding in ABAP.

But before I move ahead, I would like to give you a short background on ABAP. Of course everyone of us are well aware of the history of ABAP. But I feel this is important to know before we move ahead.

The initial R/3 days ABAP was developed as a procedural language, unlike the other procedural languages of the era. But with the introduction of Object Oriented ABAP, it has adapted to the principles of object oriented programming. It’s now similar to any other popular object oriented programming languages like java or C++, as it has concepts like inheritance, polymorphism, class & objects.

Today, object oriented ABAP is used more often to simplify the overall programming model.

Key features of Object Oriented ABAP are the following:

  • Data abstraction and encapsulation
  • Code redundancy minimal
  • Enhanced data-security & access
  • References can be drawn from real-world entities and used in modelling
  • Forms an effective programming structure.

Now having said this, most of you might have guessed where the discussion is tending to.

Clean Design of Classes

Now most of us need to develop a class here and then to support various business objectives. And to do so, the easiest way, many of us choose is to create static classes with static methods and put our code into these methods and consider our job is done.

But do we consider the following points:

Are we actually imbibing the Object Oriented Behavior?

Does our class have any authenticity?

Well, to answer the first question. NO, we are not following the object oriented behavior. And to answer the second question, the authenticity of a class can be proved if it has a test class associated to it.

So let’s start with a simple example of a static class.

Now in this example, there is no abstraction nor encapsulation. Also, data security and access is NULL. Any body consuming this class, can access the members and can change the value of it. Also, the sole purpose of OOPs of having member functions, i.e., methods which operate on the members goes for a toss. Another, aspect from the authenticity point of view, no double class can be created and injected for this class during testing.

So, how can we address such a situation?

  • Always define methods and attributes as instance components.
  • Use singleton pattern only if really required.

This is a better design than before, as the attribute is private now. Hence, security and access to the data in the class is only possible via the method(s). So now we have restricted the member of the class to be manipulated by any consumer. Also, since there is no static method, a consumer needs to generate an instance to access the member functions, i.e., the method(s). So the member functions are bound to the instances generated. However, still the design is not perfect. Consider the following scenarios.

  • A user class needs to refer to this class. Therefore, it is not possible to replace this class with another class without changing the user class.
  • From testing purpose a double class needs to be a subclass of this class. Therefore this class cannot be final.

So, the above limitations can be removed by introducing an interface. User classes can refer to the interface and thus concrete on the methods and attributes they need. All other methods and attributes are private or protected and thus hidden or abstracted. Only immutable  & read only attributes are public.

Again, this is a better design but not very much on the cleaner side. We are able to remove the dependency of the user class which refers to our class by providing an interface for implementation by the user classes which needs to refer to our class. Also, as per to testing purpose, the double creation is now possible by using the interface, thus our class can be made final now.

However, for a consumer class, object creation is technical and complex as the constructor will have to offer optional parameters to allow the creation of different type of objects (use cases). And if the constructor contain all the logic and dependencies, these are going to be a part of every unit test and need to be inherited by subclass doubles. Also, by the look of the constructor we cannot ensure that if the class is singleton or not.

As a savior to above described limitation, offering at least one creation method per object type will allow simple and readable object creation with fewer (mostly non-optional) parameters. To enforce the exclusive use of the creation methods, the instantiation of the class needs to be made private. Also, by the labeling of the creation methods, we can clearly denote, if the instance to be returned is of singleton nature or not. [get for singleton instances and create for non-singleton instances]

This is a far better design than from what we had started. However, still there is a direct dependency from the class as the static creation method will be used. If many classes consumes this class, they will use the static creation method offered to instantiate the class. If tomorrow we need to replace the class with some other class, all the consuming classes needs to be modified. Also, a user class cannot collaborate with double class for isolated tests.

Hence, a better design will be to delegate the object creation for this class to a factory class. The user classes are no creator any longer. As global friend, factory class is the only class to access private creation methods of this class.

Now we can consider this to be a clean design, where we have factory to provide us with objects for different scenarios. Also, if tomorrow your class needs to be changed, the creation logic needs to be changed in the factory. Thus the consumer classes are void of any modifications.

This was a humble attempt form my end to explain how classes should be designed using Object Oriented approach adhering to a clean design concept. Kindly comment your feedback on this and if the community likes it, I will be share more content on the clean design aspect. Anyone can reach out to me with their queries on LinkedIn as well.

Since we all in a grave situation because of the COVID-19, lets utilize our free time and contribute as much possible to SAP community to build simple and robust code-base for the future.

#StayHome #StaySafe



You must be Logged on to comment or reply to a post.
    • Thanks Peter Inotai!

      I have taken references from the Clean ABAP guidelines. Perhaps I will add a reference section to the blog with the link.

      However, In my blog, I tried to draw the approach of refactoring code to move towards a cleaner design. I have emphasized more on each step and the advantages and disadvantages of that particular step, which I felt is missing in the Clean ABAP guidelines. The Clean ABAP Guidelines, is more towards giving a holistic view rather than explaining the micros.


  • I agree with Peter.  The clean code area ABAP guidelines is a source where more than one person has updated, given opinions, and different options.

    Now some people may not want to go there.  Yes, it might be hard to understand.  (In places it is hard to understand.)  One of my favorite blogs is here.  It’s a bit old, and I didn’t re-read all of it.  I had it bookmarked.  You might want to include it at the end of your post.

    It would be great if you could show some code.  Or at least something instead of class_1.  It would really help out when doing the step by step to upgrading your code.

    Thank you for the nice blog!

    • Hello Michelle Crapo,

      Definitely I appreciate your remark. I will take some time out and go trough the blog mentioned by you, and if it is relevant to the scenario will surely incorporate the link to this blog.

      Also, I really appreciate the feedback for an actual example. At present, I do not have a example wherein the above points can be demonstrated. I need to create one. Once, I have created some example, then will update the blog with the examples.

      Thanks you for the honest review. 🙂

  • Hello Tamit Kumar Das Sharma,

    as I see it, your title is misleading: IMO it should be about the Factory Design Pattern for the creation of objects. You propose to use a factory method or a factory class to keep the ability to change the behavior by injecting another class implementing the same interface.

    This is different from the class design, where the fundamental design principle is to divide the problem domain into partitions with high cohesion and low coupling. In the object model we prefer modularity based on abstraction (cf. the power of abstraction). Design guidelines like Single Responsibility and Separation of Concerns are used.

    No matter how little time is spent thinking about design, one must assign responsibilities to objects. i.e. decide if we need more than one class, and which class should implement a given method.

    This is what comes to my mind when I think about class design.

    best regards,