Modularization of main program using OO

[Former Member]

Hi OO Gurus,

How can we modularize the main program using OO concepts?

I have seen many programs using OO programming, but PERFORMS have been used to modularized the main program code.

It seems odd to me that we are using ABAP OBJECTS, but using the PERFOMs for modularization, which is purely procedure oriented programming.

Although I understand that making PERFORMS are nothing more than bundling your code so that it becomes manageable and understandable, and it is fine if we are using object oriented concepts inside our program.

But still want to know if there is any better way to modularize the main program using OO?

Thanks in advance,

Raveesh

[Former Member]

Hello,

check if this helps you:

http://help.sap.com/saphelp_nw70/helpdata/en/33/488d08d1db11d4b2e90050dadfb92b/frameset.htm

Regards,

Pedro

[nomssi]

Hello Raveesh,

keep in mind there is [no silver bullet|http://c2.com/cgi/wiki?NoSilverBullet].

You can replace PERFORM with a static method.

Horst Keller advocates separation of concern in this [blog|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/6369] [original link is broken] [original link is broken] [original link is broken];.

I often create a local controller class, say LCL_CRTL, with a static main( ) method and a class that will encapsulate all selection screen parameters. The main( ) method will create objects as needed and trigger the processing. My code then looks like

INITIALIZATION.
  lcl_ctrl=>init( ).

AT SELECTION-SCREEN.
  lcl_ctrl=>user_command( sscrfields-ucomm ).

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

best regards,

J.N.N.

[Clemenss]

let me add some thoughts to what has been saifd already:

At least in our system, the where-used-list for methods of local classes does not work as expected, especially if you use seoarate include files for each methods implementation. Also, the maintenance of local classes is difficult if you don't put everything into a separate include.

On the other hand, you can CALL SCREEN in a local method of a program but not in a method of a global class because screens are bound to report, module pool or function group.

We were succesful with this approach:

Define a global class for modularization of functionality.

Declare a local class inherited from this class. Add public methods CALL_SCREEN and CALL_SELECTION_SCREEN here if you need special screen processing.

Instantiate (create object) of the declared inherited class in EVENT INITIALIZATION or LOAD_OF_PROGRAM.

Create methods for all screen events (start-of-selection, at selection screen, etc).

So the program will just have a DATA statement for the inherited class and one method call for each event used.

The rest can be done in the methods implementation.

And, honestly, you can modularize using performs, but you must modularize much more with classes and methods. A method needs a clearly structured interface and inside the method of a global class only local data, interface and attributes of the class are known.

Regards,

Clemens

[samantak_chatterjee]

Hi,

It wouldn't be right to judge ABAP Objects with such a case to case basis. While doing development in ABAP , you will find that classical ABAP still holds an advantage over OO ABAP . But, using OO ABAP has much more advantages which will not be met in normal ABAP Programing.

Have a look at this following link for a complete view of the [Why You Should Use ABAP Objects|http://help.sap.com/saphelp_em70/helpdata/en/60/8c94422533c46ae10000000a155106/content.htm]

Also, what ever has been mentioned in the previous two post are very much valid and I guess everyone will agree with that. Even, you can use ABAP Objects to reuse the functionality across components which will be much more helpful.

Hope this will help. You can also have a look at the various blogs/wikis which will gave you numerous examples regarding this topics.

Hope this helps.

Thanks,

Samantak.

[Former Member]

SAP uses ABAP Objects in new developments and makes effort to eliminate classic procedural approach. Why? Because object-oriented context is much more rigorous and enables things which cannot be done in a procedural model. ABAP objects enables to build much more robust applications. SAP recommends to always encapsulate functionality into classes and build applications with separation of concerns in mind. This means that you should:

a) create a class which encapsulates main application logic,

b) encapsulate screens (Dynpros) in function modules which call local classes inside,

c) create classes for database accesses, for example using persistent objects.

Info a)

The best approach is to build a singleton class, for example you may encapsulate a report like that:

CLASS lcl_report DEFINITION CREATE PRIVATE FINAL.
  PUBLIC SECTION.
    CLASS-DATA self TYPE REF TO lcl_report.
    CLASS-METHODS class_constructor.
    METHODS constructor.
    METHODS run.
  PRIVATE SECTION.
    DATA rcl_alv TYPE REF TO cl_salv_table.        "View
    DATA rcl_db TYPE REF TO lcl_database.         "Database
    ...
ENDCLASS.
CLASS lcl_report IMPLEMENTATION.
  METHOD class_constructor.
    CREATE OBJECT self.
  ENDMETHOD.
  METHOD constructor.
    ...
    CREATE OBJECT rcl_db.
    ...
  ENDMETHOD.
  METHOD run.
    ...
  ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
  lcl_report=>self->run( ).

Info b) Generally, the same approach as above, method similar to run may make CALL SCREEN statement.

In dialog modules you should call respective methods, for example

lcl_screen_100=>self->pbo( )

,

lcl_screen_100=>self->pai( ok_code )

.

Info c) Create a separate class and instantiate it in an applications constructor as shown above.

To sum up, SAP recommends to use ABAP Objects always and forget about procedural approach.

[SuhaSaha]

Hello Krzysztof,

I beg to disagree on 2 points:

1.

Create classes for database accesses, for example using persistent objects

I would rather define a local class method & code Open SQL statements in it than create Persistent Classes. I don't agree Pers. Classes are substitute for Open SQL or rather never meant to be.

2.

SAP recommends to use ABAP Objects always and forget about procedural approach.

Still there are some techniques where you can't do away with Procedural ABAP. As you've mentioned you need FMs to encapsulate screen in an OO-Transaction & who can forget our RFMs !!

Comments are welcome.

BR,

Suhas

[Former Member]

Dear Suhas,

1. Persistent classes are useful for simple db accesses (1 table), i do agree that they are not useful for complex queries. For simple applications it is better to create just separate private methods which access database, I do agree. But mixing database accesses and processing the results in the same block is not good. If you have a huge application which makes many complex queries it is useful to arrange it in a separate layer via a separate class.

2. This is about philosophy - of course, we must use old techniques in some places, such as RFC-enabled FMs, however inside you should make a redirection into the OO-context.

Regards

Edited by: Krzysztof Usowicz on Sep 13, 2010 7:57 PM

[Former Member]

Hi All,

Thanks a lot for your replies and guidance. All the replies were really helpful to me.

In the meantime, I also read the books ABAP Objects: ABAP Programming in SAP Netweaver by Horst Keller and

ABAP Objects book by James Wood which also clarified many of the concepts.

I liked the way Keller has modularized his programs in the ABAP Objects books using a static main method, taking the clue from JAVA I think.

Till now, I am pretty clear with the modularization of main programs. So I am marking the thread as answered.

I will come back for your help if I get stuck somewhere.

Once Again, thanks a lot for your help.

Regards,

Raveesh