topic Re: good/bad programming from OOPS perspective in Application Development and Automation Discussions

good/bad programming from OOPS perspective

kiran_k8 — Mon, 27 Nov 2017 09:22:47 GMT

Folks,

If I have one INCLUDE for all CLASS DEFINITIONs and one for CLASS IMPELEMENTAION and invoking those class in the main program, will be considered as a bad programming approach from OOPS perspective ?

ZPROG.

ZINCLUDE1."for all class definitions

ZINCLUDE2."for all class implementations

invoking those class and methods here in the ZPROG.

(or)

Defining all the class definition and implementations in ZPROG (without using INCLUDES) and then invoking them there itself.

Is having an INCLUDE comes under the purview of using OOPS in the first place or INCLUDES will be considered as Classical approach of programming.

Kindly opine.

Thanks,

K.Kiran.

Re: good/bad programming from OOPS perspective

SuhaSaha — Mon, 27 Nov 2017 09:41:06 GMT

Hello Kiran,

As per the ATC/SCI/SLIN checks the class definition include [ (L)Z...Dnn ] should be defined in the TOP include of the program or function-pool. The implementation include [ (L)Z...Pnn ] should be part of the main program.

If you don't follow this structure, then you get a warning message from the checks.

Cf. https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/index.htm?file=abensource_code_modular_guidl.htm

Personally i don't follow this structure when defining reports. It's easier to have everything in one place & makes life easier when refactoring.

IMHO i don't relate using(or not using) includes to OOP. Infact a CLASS-POOL itself is structured in several includes!

BR,

Suhas

Re: good/bad programming from OOPS perspective

pokrakam — Mon, 27 Nov 2017 11:47:57 GMT

Completely agree, I don't think SAP guidelines are appropriate in this instance.

There's a technical reason too: using Eclipse it's a pain to work with synchronization of definitions and code in separate units, so I gave up on that a long time ago. In my opinion it's better to group classes by function if anything.

Re: good/bad programming from OOPS perspective

UweFetzer_se38 — Mon, 27 Nov 2017 12:08:59 GMT

The historic intention of Includes was

prevent the editor from loading the whole source code because of a low network bandwith
reusage of code

Regarding 1.) I think in this times we just can ignore this

Regarding 2.) the use of local classes in your Z-Report tells me, that you will never reuse your code

Conclusion: don't use Includes at all, there's really no need of them anymore.

Re: good/bad programming from OOPS perspective

Sandra_Rossi — Mon, 27 Nov 2017 12:24:49 GMT

If think there's also point 3. Includes can still be useful for organizing source code for a better readability. I like to see the main code immediately when I display the main include of the program.

Re: good/bad programming from OOPS perspective

UweFetzer_se38 — Mon, 27 Nov 2017 12:36:11 GMT

The only "main code" in my programs nowadays is

NEW app( )->main( ).

Because we are not using any global variables anymore (of course 😉 ), the report always starts with the Class definitions (or selection screen).

To navigation to the statements (main method) we have the outline or quick-outline (<ctrl>-O).

So, I can't really agree that there is a point 3.

Re: good/bad programming from OOPS perspective

SuhaSaha — Mon, 27 Nov 2017 13:14:23 GMT

Bingo se38 🙂 Code snippet from my productive code

Maybe it's a good idea for me to switch to

NEW app->start_main( ).

Re: good/bad programming from OOPS perspective

pokrakam — Mon, 27 Nov 2017 13:30:42 GMT

Maintainability can be a reason to split large programs.

If a developer wants to change a piece of code they will lock the entire report in a transport. If FOO classes are in include A, BAR classes in include B, and SALV classes in include C, then developers can lock, work on, and transport these independently.

Re: good/bad programming from OOPS perspective

UweFetzer_se38 — Mon, 27 Nov 2017 13:49:46 GMT

Hmm, maybe the design of the report is wrong...(?)

If it's really such a large program, you should extract classes into global workbench classes.

Advantage: every method is locked separatley in a transport request.

In my opinion only the program logic (the "App", flow logic) should be a local class. Every business object should be a workbench class, although they are not used in other projects.

Re: good/bad programming from OOPS perspective

pokrakam — Mon, 27 Nov 2017 14:53:37 GMT

I guess it's a matter of approach. I prefer to keep things as local as makes sense. It only takes a couple of minutes to turn a local class into a global when it makes sense.

I agree with business objects, but I see little benefit in globalising internal classes just for the sake of program size. Typical examples of local stuff: MVC controllers, SALV views and support classes, and any report-specific functionality. This can grow quite big already. Sometimes I will group individual SALV controller and related view and support classes into their own includes.

Re: good/bad programming from OOPS perspective

UweFetzer_se38 — Mon, 27 Nov 2017 15:01:51 GMT

Ok, than my question is: where do you see the advantage of an Include against a global class?

Re: good/bad programming from OOPS perspective

Sandra_Rossi — Mon, 27 Nov 2017 15:49:48 GMT

My point was also an extra point to the historic reason.

Nowadays, if you have local classes, there might be many class definition lines before START-OF-SELECTION. NEW app( )->main( ). (or even many lines of selection screen as in Suhas example)

I still prefer to put these definition lines in one extra include, just to keep the main part immediately visible, but of course with only one line of code, then going to the end of the source is my first reflex. So, INCLUDE or not, it's not a big deal.

Re: good/bad programming from OOPS perspective

retired_member — Mon, 27 Nov 2017 16:23:13 GMT

We recommend to organize large programs in includes.

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

For class pools and function groups it is a must anyhow.

For reports, it is your decision, from which point on, it is better to create includes.

This is independent from ABAP objects.

For large local classes, it is not a bad idea to put declaration part and implementation part into different includes, where the declaration include then should be included in a top include.

But never, never, never reuse includes.

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

Re: good/bad programming from OOPS perspective

retired_member — Mon, 27 Nov 2017 16:35:42 GMT

It is not only about reports but also about function groups that you still might use for technical reasons (update, classical screens).

Here all productive code should be implemented in local classes and these in their includes. It makes no sense to create global classes for the internals of function groups or other kinds of programs, especially since we don't have a package section.

Re: good/bad programming from OOPS perspective

pokrakam — Mon, 27 Nov 2017 16:42:11 GMT

Horst just provided one part of my intended answer when he wrote "But never, never, never reuse includes."

I treat includes are local to the program (although people can break those rules but then that's their responsibility). Global classes are effectively released for all & sundry to use as they please.

It's partly personal style too, I write code and refine, rename and refactor often before my final version is ready, this is quick and easy in local classes, especially with Eclipse.
My globals often start life this way too for the same reason - I also don't like 15 transports with method renames and deletions, which tends to be the case on projects with daily transports.