OO programming or Procedural?

[Former Member]

Hello i have been working with SAP-ABAP for about 4 months and i just finished a course in OO programming. I Would like to understand if i should always program everything in OO concepts or should i use procedural programming on minor programs?

To me it seems like doing everything in OO way is the more reasonable choice because the SAP environment will then have more redundancy and will be more robust but i would like to hear some opinions about this topic from other members of the community

Regards

[matt]

You should always use OO. For a start, FORM and PERFORM are now obsolete language components. However, the main reason is that minor programs from time to time become major programs. (Can you just add this? Can you make it do that? etc.). If you've programmed it properly in the first place, the cost of maintaining and enhancing will be reduced.

You don't have to use global classes. You can use local classes. Sometimes I've needed to make a local class global, but that's a relatively straightforward task.

[Former Member]

Thank you for the quick rspoonse, it makes more sense now.

Regards

[horst_keller]

https://help.sap.com/http.svc/rc/abapdocu_752_index_htm/7.52/en-US/index.htm?file=abenabap_obj_progr...

[Former Member]

horst.keller I found this link about SoC(Separation of concern) while Reading the link you provided. it gave me a clearer Picture on how to implement OO techniques in programs.

https://help.sap.com/http.svc/rc/abapdocu_752_index_htm/7.52/en-US/index.htm?file=abenabap_obj_progr...

[Sandra_Rossi]

Of course, if it's a basic code of 10 lines (sometimes it's needed for interfacing two applications), I don't see why we should use OO, as the procedural way would be far more readable.

[matt]

As I said:

...the main reason is that minor programs from time to time become major programs. (Can you just add this? Can you make it do that? etc.). If you've programmed it properly in the first place, the cost of maintaining and enhancing will be reduced.

I wouldn't consider 10 lines of code not inside a method to necessarily be procedural. If the granularity is small enough, it really doesn't merit any kind of description beyond perhaps "script". I'd disagree that encapsulating the script within a method is less readable. If you're comfortable with OO, there's no difference in readability. And if you're not, then perhaps readability is (subjectively) 99.99% rather than 100%.

...bit of code...

compared with

CLASS thing DEFINITION.
  METHODS do_simple_stuff.
ENDCLASS.

CLASS thing IMPLEMENTATION.
  METHOD do_simple_stuff.
    ...bit of code...
  ENDMETHOD.
ENDCLASS.

new thing( )->do_simple_stuff( ).

However, I'm intrigued by what you mean by 10 line interfacing two applications means. Can you give an example?

[horst_keller]

Unfortunately, ABAP misses one thing, the "submitable class" 😞

[Sandra_Rossi]

For instance, utility program for batch input session with SPA/GPA parameters not reset :

REPORT.
PARAMETERS p_tcode TYPE tcode OBLIGATORY.
TYPES spa_value TYPE c LENGTH 255.
DEFINE mac_set_parameter.
  PARAMETERS p_spa&1 TYPE tpara-paramid.
  PARAMETERS p_val&1 TYPE spa_value.
  IF p_spa&1 IS NOT INITIAL.
    SET PARAMETER ID p_spa&1 FIELD p_val&1.
  ENDIF.
END-OF-DEFINITION.
mac_set_parameter : 01, 02, 03, 04, 05, 06, 07, 08, 09, 10.
CALL TRANSACTION p_tcode WITH AUTHORITY-CHECK.

Or any utility program in fact.

EDIT: with authority-check added.

[matt]

So effectively a script,

Looks a little unsecured though. 🙂

[Sandra_Rossi]

It was an example of course. If you call 10 lines of code a script then yes it is a script of course. Anyway, I really don't see why we should encapsulate it as ABAP Objects.

[Sandra_Rossi]

and of course there are probably many other reasons for 10 lines of code. And not only in an executable program. In a RFC-enabled function module, you won't embed these lines in a local class.

[horst_keller]

Inside classes there are stricter syntax rules which are valuable even for 10 lines of code.

It's not a big deal to prepare a small template and copy that even into smallest programs as I have done for all the executable examples of the ABAP docu.

[Sandra_Rossi]

But for the clarity of the ABAP examples, the class encapsulations have been grayed out to focus on the procedural part, and that was a very good idea 😉

But believe me or not, I always write my programs using OO. I'm simply acting as the "Devil's advocate". French proverb : there is always an exception to a rule.

[pokrakam]

My humble opinion is that it has little to do with length of code. Your example deals exclusively with classical ABAP elements, therefore that particular usage makes sense to use classic ABAP.

On a more general note to this thread, in Eclipse it's hardly an effort: lcl<ctrl-space><enter> et voila: a ready-to-use class template.

Of course you can also roll your own templates, and personally I've automated a few things using TextExpander (mac) and TyperTask (win), because a) that way the templates work consistently across Eclipse and SAPGUI editors, and b) I find the <ctrl-enter> bit an unnecessary effort 🙂

[horst_keller]

And I sometimes don't use classes ...

[Sandra_Rossi]

If it's a more lengthy code, it's often possible to split the code in 2 or more procedures for more readability (functional splitting of course). You're right, it's not a matter of time for writing the extra code. Not using OO for a "script" is just a matter of readability. Differently said, I prefer to see directly the effective code without the mess around.

But generally speaking, I agree with Matt's answer of course. I think the original question was not about 10 lines of code, and was about code with procedures, so use ABAP Objects for sure. Matt's answer "You should always use OO" is not "You must always use OO", I just wanted to add my 2 cents.

[matt]

Why not do it?

• It's little effort to ecapsulate
• You benefit from the stricter syntax checking rules, which mean you can't have those old ambiguous ABAP statements
• You future proof if later there's a need to enhance.
• You make re-use easier.

[matt]

Well... if you work for me, you must use OO. But that's mainly to get folk who are reluctant to get into the habit. It also gets people away from what I think is a very bad habit of "well, it's only 10 lines of code/a utlitiy program/a one off kind of mentality, and apply rigour and best practice to all their work.

[FredericGirod]

Hi,

this is maybe the better question to have a little fight between developers, and the famous INNER JOIN vs FOR ALL ENTRIES 🙂

As I understood the Oo has to be used when the logic is based on the data, and the Procedural when the logic is based on the process.

But I'm not sure it is a good idea to force people to code always in Oo, sometimes it's really difficult to debug Oo program.

And I am curious about the memory consumption and if Oo is really faster than simple procedural program??

Regards

Fred

[pokrakam]

Sometimes it’s really difficult to debug a procedural program. The reason has less to do with the strategy and more with the developer..

The same answer applies to your question about performance etc. While oo does technically incur a small overhead, it makes strategies for efficient reuse much much easier, which more than makes up for it.

I’ve seen well written 10,000 line procedural monsters and sprawling masses of incoherent classes. The technology was a secondary factor. The main point is that oo makes it easier and almost forces you to be better structured.