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: 

Needing Evidence on the Advantages of ABAP OO

Former Member
0 Kudos

I am looking for the warm and fuzzy that I've yet to experience while being convinced about this one particular advantage of OO. Particulary involving multiple creation of objects, or instances occurring at one time.

I know the syntax of local and global classes, have done quite a bit of reading, and am familiar with OO coding, but seem to be missing the real-world implications of its use and its superiority to Function Modules in Function Groups.

My understanding is that with data in Function Modules within a Function Group, unlike attributes in a class, a single value in a field has one existence (and value) at runtime for the Function Group. However, for attributes, or objects, in a class, multiple instances may occur at one time. While even as I say this it confuses me, because I do not think I've seen an example of a convincing custom application in SAP in my experience only. Not that I do not doubt SAP's intent, I just am not getting it.

Can any experienced, and already convinced, ABAP OO programmer try to explain an application (in its simplest terms, if possible) where I would create multiple objects where this principle can be seen. And then tell me why I wouldn't be able to accomplish the same thing with Function Modules within Function Groups. Especially, if you have experienced a real-world implementation of this claim using OO.

What I would really like is to have some code that uses Function Modules, then some classes, that both accomplish the same results, that would prove to me that OO, and its classes are superior to Function Modules in Function Groups.I suppose what I really need is an application where multiple instances of the same object is being used, and its advantages.

I will listen to any, or all explanantions. I will accept any code, links, etc. Anything, please to settle my thinking and convince me once and for all.

Thank-You.

Edited by: TMM on Jun 17, 2009 4:36 PM

Edited by: TMM on Jun 17, 2009 4:37 PM

1 ACCEPTED SOLUTION

naimesh_patel
Active Contributor
0 Kudos

I understand your confusion rather frustration on having the Objects instead of the FMs.

Let's first see how it is powerful than the FM.

You have an application which can create a different CARS. For the OO design, you can create a super class LCL_CAR and than you can create subclasses LCL_SEDAN for Sedan, LCL_SPORTS for Sports car from this LCL_CAR Class. You can put all the common attributes of the cars in to the class LCL_CAR e.g. COLOR. You can create the car specific attribute in the subclass. E.g. ENGINE POWER in the LCL_SPORTS. Since your class LCL_SPORTS is a subclass of the LCL_CAR, you would all the protected attributes in the LCL_SPORTS class.

To do the same thing with the Class, you need to create separate FGs eg. ZFM_SPORTS, ZFM_SEDAN. You need to define all the attributes in both the FGs. Any new common attribute, than you need to add it into both FGs. More over you can't control the visibility of all the global data declared in the FG's Top include.

The good example (might be complex one) would be the SALV model. SAP has introduced an SALV model for ALV development. Up to release 640,

To create a Fullscreen ALV than you need to call the FM REUSE_ALV_GRID_DISPLAY

To create a List ALV, you need to call FM REUSE_ALV_LIST_DISPLAY

To create a OO ALV on the custom container, you need to create an instance of the object CL_GUI_ALV_GRID.

By introducing the SALV model, SAP has streamlined the interface to create the any type of the above listed ALVs by just creating the object of the class CL_SALV_TABLE. We don't need to worry about the different setting for the different ALVs e.g. Field catalog for the FM REUSE.. uses from the SLIS where as the field catalog for the CL_GUI_ALV_GRID would be LVC_T_FCAT type. If you use the CL_SALV_TABLE, you can the type of ALV display on the fly.

To see the so many instances of the same class or object, you can explore the attribute R_COLUMNS of class CL_SALV_TABLE which is type ref to class CL_SALV_COLUMNS_TABLE. This class has the attribute T_COLUMNS, which contains the actual reference of all the objects.

Run the report SALV_DEMO_TABLE_SIMPLE. Put a brekpoint on the statement cl_salv_table=>factory. Check the object GR_TABLE. See the attribute R_COLUMNS and try to explore the columns table.

Regards,

Naimesh Patel

9 REPLIES 9

RichHeilman
Developer Advocate
Developer Advocate
0 Kudos

Firstly, I'm not going to attempt to convince you, I'm only going to state a fact, and give you an example. First the fact is, that ABAP OO is and will be used by SAP development moving forward and function modules/groups will usually only be used when they are needed, such as when you need to call functinoality from outside of the system, like an RFC enabled function. But you will then probably see a call to a class/method immediatly inside the source of the function then, so the functions would just be a wrapper. This is how we did things on the project that I was working on. Also, if you have explored Web Dynpro ABAP, you would notice that it is ALL ABAP objects, so the advantage of using it here is really a null point. It is a must.

Now, if you are continuing to develop dynpros, and report programs, there is nothing that will force you to use ABAP objects, but again, it is good to use to be consistant across your developments. An example of the use of ABAP objects would be around business classes. These classes are not a defined class type in ABAP, but more of a description of what the class is/does. So lets take sales orders for example. Lets say that we create a class called ZCL_SALES_ORDER whose has attributes, like Sales Order Header, and Sales Order Item. This class then has methods like READ_HEADER, or READ_ITEMS, MODIFY_ITEM, SCHEDULE_ORDER, etc. So you would use this class to act on one specific sales order. The instance of the class would contain sales document data for exactly one sales document, and using the READ methods would give you this data, and so forth. You could then have a table of instances of sales order class in which you could process them in a loop. So if you look at it this way we look at each sales order as an object, which contains its own attributes(usually private) and can only be acted on by the methods of the class. This is just one very simply/small example.

Regards,

Rich Heilman

0 Kudos

Thanks Rich. I was trying to be careful in the wording of my post. Beacuse I plan to continue to learn and use them. I just get hung-up on the multiple instance thing. I have come to rely heavily on the suggestions of SAP, like to use OO, and I will do so. Again, I haven't reached a point where I am seeing this definite benefit. I know its there, but I guess I will just keep creating them and it will eventually hit me.

Thanks Again.

Edited by: TMM on Jun 17, 2009 4:55 PM

Edited by: TMM on Jun 17, 2009 4:56 PM

Edited by: TMM on Jun 17, 2009 4:57 PM

0 Kudos

Well, using instances of classes, only makes sense when it makes sense to do so. You can of course create classes with static attributes and static methods. So you have one set of data and you act on that data with static methods. This is similar to the way function groups work. But again, instances of classes are used when you are referring to specific objects and want to deal with those objects in a simlar manner with a different set of data, like in the sales order example above.

Regards,

Rich Heilman

naimesh_patel
Active Contributor
0 Kudos

I understand your confusion rather frustration on having the Objects instead of the FMs.

Let's first see how it is powerful than the FM.

You have an application which can create a different CARS. For the OO design, you can create a super class LCL_CAR and than you can create subclasses LCL_SEDAN for Sedan, LCL_SPORTS for Sports car from this LCL_CAR Class. You can put all the common attributes of the cars in to the class LCL_CAR e.g. COLOR. You can create the car specific attribute in the subclass. E.g. ENGINE POWER in the LCL_SPORTS. Since your class LCL_SPORTS is a subclass of the LCL_CAR, you would all the protected attributes in the LCL_SPORTS class.

To do the same thing with the Class, you need to create separate FGs eg. ZFM_SPORTS, ZFM_SEDAN. You need to define all the attributes in both the FGs. Any new common attribute, than you need to add it into both FGs. More over you can't control the visibility of all the global data declared in the FG's Top include.

The good example (might be complex one) would be the SALV model. SAP has introduced an SALV model for ALV development. Up to release 640,

To create a Fullscreen ALV than you need to call the FM REUSE_ALV_GRID_DISPLAY

To create a List ALV, you need to call FM REUSE_ALV_LIST_DISPLAY

To create a OO ALV on the custom container, you need to create an instance of the object CL_GUI_ALV_GRID.

By introducing the SALV model, SAP has streamlined the interface to create the any type of the above listed ALVs by just creating the object of the class CL_SALV_TABLE. We don't need to worry about the different setting for the different ALVs e.g. Field catalog for the FM REUSE.. uses from the SLIS where as the field catalog for the CL_GUI_ALV_GRID would be LVC_T_FCAT type. If you use the CL_SALV_TABLE, you can the type of ALV display on the fly.

To see the so many instances of the same class or object, you can explore the attribute R_COLUMNS of class CL_SALV_TABLE which is type ref to class CL_SALV_COLUMNS_TABLE. This class has the attribute T_COLUMNS, which contains the actual reference of all the objects.

Run the report SALV_DEMO_TABLE_SIMPLE. Put a brekpoint on the statement cl_salv_table=>factory. Check the object GR_TABLE. See the attribute R_COLUMNS and try to explore the columns table.

Regards,

Naimesh Patel

0 Kudos

Naimesh, ThankYou for your informational reponse.

I actually drew little sketches of your examples and I looked at the code you suggested for the ALV Class.Your explanation is getting me closer, but I'm not quite there yet.

I see great advantages in the sharing of logic now between SuperClasses and its SubClasses, thanks to your LCL_CARS example. Because, copying duplicate code between function groups can always lead to not only more work, but also issues if not careful. We here at my offic have combined separate SAP instances for different Business, and since program names, Function Modules, tables, etc. were the same names in two separate SAP instances of R3, everything had to be renamed, you can imagine how much work that is! I guess I am thinking with objects, we may be able to possibly have one SuperClass that share the needed attribute of the two businesses functionality, but each would neeed its own specific, or prtotected attributes also. Of course, this would have to be developed, and quite a bit of work at that. But in the future, if we decide to contain two separate business processes that share functionality, the Classes will be the way to go.

I looked at the objects in the CL_SALV Class, including R_COLUMNS and I ran the demo with break-points. I assume the point you are trying to make is that besides not being bogged down with two separate Function Groups, for a list vs. a grid, is that things like columns are used over and over again in a fullscreen execution. And at the sametime if a different ALV is needed the same class creates the same thing with shared logic.....Great!

Two sticking points:

1)What do you mean by 'More over you can't control the visibility of all the global data declare the FG's Top include.'?

2) I wish I could imagine a design scenario for Sales Orders that would need to create multiple instances that would be advantageous, because even with Rich's explanation of a Sales Order Class, my real-world scenario is difficult to envision.

Thanks Again for your GREAT explanation!

0 Kudos

One of the big advantage of the Objects is you can set the visibility of its components. If you make them as the private than nobody from outside will able to see it. On FG, you don't have this control.

Regarding your question about how and when to use the table of the objects:

I recently posted some blogs about the Object Oriented Design Principles. Check this post [OCP with Business Scenario|https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/14457] [original link is broken] [original link is broken] [original link is broken];. You can find the Code for this example in this WIKI [OCP Example|https://wiki.sdn.sap.com/wiki/x/cYJCBg]. In this example, I am storing different type of the object references in the table LT_OBJ. LT_OBJ is type ref to interface LIF_SUBOBJ. I store different type of objects in this table LT_OBJ e.g Material, Customer.

Regards,

Naimesh Patel

0 Kudos

Thanks for yor patience guys, I'll get there.

matt
Active Contributor
0 Kudos

This is real world stuff:

After an application has been developed, it has happened a few times that I've wanted to use the same logic (or very similarl) in a different context. By subclassing, I'm able to reuse what I've already developed, with little effort. All I've had to do is redefine one or two methods of the main class.

I often develop stuff that has to run on different versions of SAP. Subclassing here is very useful, as the subclass for ECC 6.0, for example, doesn't even have to pass syntax checking in 4.6c!

Using composition, I was able to develop an ["ABAP Decision" process type in BW|https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/uuid/30664504-40dd-2a10-3794-db7b4190bef3] - re-using what SAP developed. The only coding I had to do was the variation from the standard sap.

I've developed a framework for writing Function Exits in BPS. For a new function exit, I subclass the main class, and override an initialisation method and a processing method. All the repeated stuff I was doing before is in the main class.

Generally, I find that developing in OO takes a little longer, but maintenance and support is much quicker. As the bulk of the cost of software development lies in the latter, this can only be a good thing. I also find that I'm reusing a lot of generic code I'm developing - e,g, I've developed a class for handling hierarchies in BW.

Currently, I'm working in the QM module, developing reports and smartforms for notifications. The first thing I did was create a class ZCL_NOTIFICATIONS, which is my Data Access class, getting the various bits of data that I need in my reports. This will be used in all my reports. Now, I could do this using Function Modules, but using the functional notation of objects, I can say

l_physnum = lr_notif->get_physnum( ).

rather than

CALL FUNCTION MODULE 'GET_PHYSNUM' IMPORTING e_physnum = l_physnum.

I think the former is neater. Also, if had a physnum in a different class, I can use the same name. With function modules, I'd have to have

GET_PHYSNUM_FOR_NOTIFICATION

GET_PHYSNUM_FOR_INVENTORY

Finally, with CONSTRUCTOR and CLASS-CONSTRUCTOR, initialisation can be done without having to remember to call the INITIALISATION function module of my function group.

matt

0 Kudos

ThankYou Matt. The responses I have received are priceless!