OOP Report structure

[Former Member]

Hi,

My background in SAP is procedural ABAP.

I'm in the middle of trying to understand OOP with ABAP.

In Java, usage of OOP is straight forward, main() will be the first method that will be called every time the program executed.

However, I'm still confuse on how is the right report structure in abap should be.

I found there are 2 OOP report structure that people commoncly used.

First is using static class method main in start of selection as below:

Report ZYYY.

.

.

.

START-OF-SELECTION.

lcl_report=>main( ).

lcl_report is local class of this report. This structure will make the report similar as Java approach. However, some source code sample that I found will have instance of lcl_report be created in main() method and private instance method will be called using the instance created. For example :

METHOD main.

CREATE OBJECT go_report1.

go_report1->gr_period = so_poper[].

go_report1->gr_bukrs = so_bukrs[].

go_report1->gr_vbund = so_vbund[].

go_report1->get_data( ).

go_report1->arrange_data( ).

go_report1->generate_output( ).

ENDMETHOD.

The second approach is the most often found for SALV usage example as shown below:

Report ZALV.

.

.

.

START-OF-SELECTION.

DATA: lo_report TYPE REF TO lcl_report.

CREATE OBJECT lo_report.

lo_report->get_data( ).

lo_report->generate_output( ).

For the first approach, there is also other slightly different option by using static method instead of creating object for the report. Below is the example.

METHOD main.

lcl_report=>gr_period = so_poper[].

lcl_report=>gr_bukrs = so_bukrs[].

lcl_report=>gr_vbund = so_vbund[].

lcl_report=>get_data( ).

lcl_report=>arrange_data( ).

lcl_report=>generate_output( ).

ENDMETHOD.

Please advice me the right way of writing ABAP program with OOP concept. Just consider me as newbie in ABAP OOP. Thank you.

~Abraham

Edited by: Abraham Bukit on Jan 4, 2010 4:28 PM

[Former Member]

Hi Abraham,

personally, I prefer to work with object instances instead of "static classes" (i.e. classes which only have static methods and attributes). This has several reasons:

- Object initialization can be controlled explicitly (static constructors are called implicitly by the runtime environment)

- Avoids the drawbacks of the static constructor (no parameter interface, no exception propagation)

- Static methods cannot be redefined. Even though inheritance might not be required when creating the class, this might become necessary later.

Regards,

David

[matt]

Typically, I use

INITIALISATION
  CREATE OBJECT my_obj.

START-OF-SELECTION.
  my_obj->do_stuff( ).

or

INITIALISATION
  CREATE OBJECT my_obj.

START-OF-SELECTION.
  my_obj->get_data( ).

END-OF-SELECTION.
  my_obj->display_data.

[Former Member]

Hi Abraham

In your sample I don't think there's a real difference between classic and OOP for a "normal" report, i.e. the report is arranged in a procedural flow in both language, but this is the first approach to meet OOP in ABAP by ABAP developers have never used OOP, probably it was the easier way to learn OOP.

START-OF-SELECTION.
lcl_report=>main( ).

U can have same result if a routine:

START-OF-SELECTION.
perform main.

There's no difference, except for the method.

In the logic below every way to define a MAIN routine can be used, so it can be used a statical or instance object.

Max

[Former Member]

>

> Hi Abraham
> 
> In your sample I don't think there's a real difference between classic and OOP for a "normal" report, i.e. the report is arranged in a procedural flow in both language, but this is the first approach to meet OOP in ABAP by ABAP developers have never used OOP, probably it was the easier way to learn OOP.
> 
> 
START-OF-SELECTION.
> lcl_report=>main( ).
> 
> U can have same result if a routine:
> 
> 
START-OF-SELECTION.
> perform main.
> 
> There's no difference, except for the method.
> 
> In the logic below every way to define a MAIN routine can be used, so it can be used a statical or instance object.
> 
> Max

Well, I agree if it looks like the same approach. However, there is difference in term of programming concept used. The first one can be identified as fully OOP since the program no longer use the concept of FORM...ENDFORM. As a note, this approach example by using main() method is taken from ABAP Object book written by Mr Horst Keller. The other example in directly create object and call instance method after start-of-selection is taken from several threads in this forum and it's more popular than the main() approach.

In my personal opinion, the reason is to imitate the behaviour of other OOP programming language such as Java or Dot Net. Maybe it will be much easier to understand ABAP OOP if the ABAP language no longer position itself in the middle between procedural and OO.

[Former Member]

That was my first consideration.

The SAP is based on ABAP language and ABAP was adapted to OOP: this was the logical step to upgrade ABAP else it would been be a "died" language without future.

I believe (that was an old discussion) SAP has thought to use JAVA (so a pure language based on OOP), but it has to do a mediation, because to leave ABAP would have meant to pay a very high cost: techincal cost but also human cost.

There were/are a very large number of ABAP developers (like me) born in tha ABAP without knowledge of OOP language, so a big risk would been be to burn them, probably that's explain as ABAP is not a pure OOP.

I don't know if and when SAP switches on to a pure OOP language, in this moment we have to different ways or concepts to do the same things: it has to be used OOP just only for particular screen object. I prefere to use OOP because it's the future for me.

Max

[matt]

Having programmed extensively in both Java and ABAP Objects. I don't find any difference in approach. To me, all this talk of "pure OOPs" is theoretical. You can be as pure as you like with ABAP Objects. You are not forced to use the non-oo parts (especially with the advent of WD4A) - you don't have to use Select-options etc... But if you think of the report events (INITALIZATION etc.) and the code therein, and the screen definition, as just being part of the "main" method, I really see little difference.

Unless I'm maintaining something old, I tend to create reusable global classes, which are then accessed within an ABAP report, or BI routine, BPS exit function etc...

[Former Member]

Hi Matt,

You are not forced to use the non-oo parts (especially with the advent of WD4A) - you don't have to use Select-options etc... 

I mostly agree, but just wanted to mention a few places, where we still are forced to use non-oo: For classical dynpros and for programs which run in the background.

Regards

David

[Former Member]

For those of us who are serious about using SAP best practices for ABAP programming, there is an excellent manual, just released by Gallileo (SAP Press), entitled Office ABAP Programming Guidelines, by Horst Kessler and Dr. Wolf Hagen Thummel, who work in an SAP group responsible for ABAP development. Their demonstration of Separation of Concerns and software layering with OO is the best I've seen so far.... worth a purchase if one is devoted to ABAP and maintaining one's skills at current SAP best practice.

Interesting to note that in current and upcoming releases, customer-facing products (like ESS and others) have been re-written in WebDynpro ABAP from Java. According to statements made by SAP staff, no new development will be done in Java, although the Java stack will be supported for the foreseeable future.

[Pawan_Kesari]

I think good design should allow you to reuse the class out of your report.

Also report logic should not neccessarily be contained in one class it could be divided into mutiple classes.

Usually I create one (or more ) class for logic and other for displaying report. This allow me to separate the logic part with UI part (sort of MVC) .

DATA : ob_logic TYPE REF TO cl_purhase_order_logic ,
       ob_alv   TYPE REF TO cl_alv_purchase_order . 

INITIALIZATION .
  CREATE OBJECT ob_logic .
  CREATE OBJECT ob_alv .

START-OF-SELECTION .
  ob_logic->get_data( EXPORTING .... ) .

END-OF-SELECTION .
  ob_logic->process_data( IMPORTING i_rep .... ) .
  ob_alv->display_data( EXPORTING i_rep ) .

Here cl_alv_purchase_order was derived from another base class and few methods were redefined to suit this report.

I am not saying this is the right way but chosing out of two options doesn;t look right to me.

[naimesh_patel]

I would prefer to use the Instance vs Static when I would be working on ABAP report where as, I would prefer Static rather Singleton Object when working on the Dynpros. In Dynpro, I don't want to re instantiate the main object again and again.

As Matt has already suggested, you should put your logic in a reusable class (global class). Your report should act kind of Controller in the MVC. Your logic should go into the Model class. You could have the specific ALV class which can work as your View class.

Whenever you design any report or something think of reusability. E.g. while design normal report think of what kind of modification you need to do if you need to expose the functionality as Web Dynpro. If you have wrapped your logic in a global class, you may be use the same class with minimal modification.

For selection parameters, I usually create one individual class. This class would have a factory method, which would accept all the selection parameters and give me the selection object. This class would have attribute type of Ranges for Select-Options. I refer the same object in my Model & view classes. So, in future, if I need to add one more parameter to the selection, I just need to change my selection class. No need of changing any other class.

METHOD main.
CREATE OBJECT go_report1.
go_report1->gr_period = so_poper[].
go_report1->gr_bukrs = so_bukrs[].
..

Regards,

Naimesh Patel

[Former Member]

This is really an eye opener discussion for me.

Looking at all these comments make me realize that there are even more approaches in writing ABAP OOP report than 2 options that I already know.

The global class usage in MVC seems to be quite make sense to be used as per current ABAP OO design and I might give it a try first.

I'm just starting to use ABAP OO in simple report, not even using it in ABAP dynpro yet but already apparent to me that ABAP OO position is still far from stable.

Maybe will still take years from now to be able purely change our technical design document from standard flow chart to pure UML diagram. In the meantime, I'll just have to prepare myself slowly shifted to Object Oriented ABAP. Thank you all for this great discussions.

~Abraham