Skip to Content
avatar image
Former Member

Create one or more instance of a class

Hey experts,

I have a question about good abap oo coding.

I have a class (e.g. cl_adjust) which will adjust some attributes of promotions.

In my Programm I have do to many things, but at a certain point, due to some Information, I have to adjust a promotion.

Now I will call the class cl_adjust to do that.

My Question now is, should I create a new Instance for every promotion (everytime I come to the point, where I have to adjust a promotion) or should I create one Instance of the class and call a method (e.g. cl_adjust->execute( IMPORTING io_promotion = lo_promotion )?

I guess, the programm ist faster, if I just create one instance?

Thanks in advance and BR,


Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

3 Answers

  • Apr 08, 2016 at 09:02 AM

    Is there a link between CL_ADJUST and the rest of your program? Does the instantiation of the CL_ADJUST do/trigger anything specific? Or is the EXECUTE method just a function module converted to a method?

    Basically, the question is if the instance of CL_ADJUST is truly required (and related to a certain 'promotion')? Or if it is only required to be able to execute the EXECUTE method.

    In case of the latter, one instance would be enough I'd say.

    Add comment
    10|10000 characters needed characters exceeded

    • Hello Sebastian,

      as I understand your question is not about algorithmic decomposition, but about how to judge a design. There is no right or wrong without context, but OO design principles help:

      1) How to design classes: make sure each class have a Single Responsability

      Craig Larman says the most important OO development skill to learn is the ability to assign responsabilities to software objects. It is challenging to master, with many degrees of freedom and yet everyone must do it from day one.

      2) How to choose between competing designs: Sandi Metz says we must make sure a class only depends on classes that changes less often than itself

      e.g. you have a relationship between classes CL_ADJUST and CL_PROM via the promotionID attribute. Promotions now depend on the Adjustment class to work properly.

      Is it likely that CL_ADJUST will change in a way that you also have to change the CL_PROM class? Then you should not separate those.

      Check this site for more information.


  • Apr 13, 2016 at 02:24 PM

    My cents:

    Sounds like your class does not represent a promotion or anything similar "object like", it basically represents a function (module). Others already gave some tips about that, it indicates the overall design could be more "OO like".

    If you want to stick with that design, i suggest using only one instance. Basically you could use a static method in this case, but SAP suggests using an object, to be more flexible if you have to change something (eg Overwrite your functionality, using a subclass).

    It won't be helpful if you make a pseudo object, creating one object for each promotion ID, only to execute that specific functionality on that promotion.

    If you want to have a "promotion object", the class should completely represent a promotion, handling everything about that promotion in it.

    kind regards,


    Add comment
    10|10000 characters needed characters exceeded

  • Apr 13, 2016 at 02:50 PM

    Good OO question, Sebastian!

    I think, you should move out the CL_ADJUST_PRICE (Lets put more descriptive name) when you think that there would be many different scenarios where your CL_PROMOTION would not differ but your ADJUSTMENT logic will. E.g. For COND1 = Do this, COND2 = Cond1 + Do something new. In this case, if you move out the logic to a separate class, you can inherit this new class when there is a different condition and instantiate the object for this specific condition.

    If you have this logic within the Promotion class itself, you would be able to achieve this level of polymorphism but you may have to create many inheritance of the promotion class. By having this calculation logic separate out would reduce the overall number of object.

    A good factory method should be created which inturn make sure instantiates all necessary objects.

    With that being said, I don't see any harm instantiating a new ADJUST object for every promotion.

    Naimesh Patel

    Add comment
    10|10000 characters needed characters exceeded