Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Create one or more instance of a class

Former Member
0 Kudos

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,

Sebastian

7 REPLIES 7

Patrick_vN
Active Contributor
0 Kudos

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.

0 Kudos

Actually the cl_adjust just covers a functionality (adjust a given promotion). The functionality could also be implemented in the main class by the same methods implemented in the cl_adjust class. I guess, it doesn't trigger anything special (whatever you mean by that).

Also, the instance is not required. You could also call Static Methods of a class cl_adjust.

If it is related to a cetain promotion? Well, you give the information of a certain promotionID (and some other information) to the class cl_adjust, and within the methods of the class you handle your adjustment.

Either you create for every promotionID an instance of the class or

I understand that I need an Instance of a class for a certain OBJECT. E.g. a class for one promotion. You create an Incstance for a special promotionID. The class represents the promotion. It contains the data of all DB-Tables related to the promotion, and all methods to update this data.

But this classes are by far the fiewest in ABAP. Most Classes in ABAP cover just a special business logic. They don't represent a special object.

Basically the question is, when do I implement a class for a special business logic, and when should I create a static class / static Methods, one instance of a class and when more instances of a class?

Dou you understand what I mean? And what my question is?

nomssi
Active Contributor
0 Kudos

Hello Sebastian,

the fundamental design principles (e.g. high cohesion, low coupling) are the same no matter the programming paradigms. The rules of thumb you will learn in one context will be detrimental in another. When you learn object oriented design pattern remember they are concepts, not reusable components so read the rationale carefully.


As good design is a good trade off, you should document your selected solution to a given problem, so we can comment and propose alternatives. With this disclaimer, I would say

1) create a new instance every time and never change the object after creation. It makes your program much simpler to reason about.

2) I do not like your class CL_ADJUST: it defines an activity / function / cf. verb adjust -  this is algorithmic decomposition. I think you should go for a promotion OBJECT that have an adjust( ) method.

With object oriented decomposition the desired / required BEHAVIOR emerges from the interaction between the OBJECTs we find/create/invent (Note it is objects, not classes, that interact, therefore my recommendation in 1).

Allow me to refer to

hope this helps,

JNN

0 Kudos

Hi,

thank you for your detailed answer. I thinks I understand you. I gues I descibed my problem not exactly. The class cl_adjust defines indeed a function and is for algorithmic decomposition. After calling the class, there are some calculations which fields of which business objects must be updated with which value. A pormotion and different depended orders, deliveries,... just some fields (0-3) in every Object.

As far as I understand OO, I should create a class for Promotions, Orders, Deliveries (with internal Tables for Data Storage and Methods for manipulating the objects). After I'm finished with the calculations, I create an Instance of the classes and hand them the information (e.g. set_attribute( name = value = ). So I should not create one Class for all Objects.

My question is about algorithmic decomposition. E.g. I have the CL_MAIN, calls CL_ADJUST /or cl_calculate_adjustments (which calculates for one promotion) calls CL_PROM, CL_ORDER,...

Would that be the right way for algorithmic decomposition? And now the question from above.

Should I create one Instance for cl_adjust or an Incstance for every given Promotion? Or should I directly create the class cl_prom instead of cl_adjust and calculate and create objects for cl_order, cl_delivey within there? But this whould then only be made for my scenario?)

I hope you understand my question(s)?

Thanks for your Help in advance.

nomssi
Active Contributor
0 Kudos

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.

JNN

ThomasKruegl
Participant
0 Kudos

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,

Thomas

naimesh_patel
Active Contributor
0 Kudos

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.

Regards,
Naimesh Patel