topic Re: Getters Methods - Exporting vs Returning value() in Application Development and Automation Discussions

Getters Methods - Exporting vs Returning value()

FabioPagoti — Mon, 05 Apr 2010 16:27:11 GMT

Hi OO Gurus,

i'm doing a test oo report. On its first version, i declared all data objects in the public section of all classes. Now, i moved all data objects to the private sections for encapsulation purposes. Therefore, i have to implement get methods for everything declared (including tables and references) in the report. My question is:

What is the best option to create get methods: Create simple methods using the "Exporting" keyword or create functional methods using "Returning value" keywords?

If i use 'exporting', i'm just able to call the method using 'call method' keywords. However formal parameter may not be fully specified (i can export tables in such method)

If i use 'returning value', i have a functional method but its parameters must be fully specified.

What's is the best option in your opinion?

Thanks!

Re: Getters Methods - Exporting vs Returning value()

Sandra_Rossi — Mon, 05 Apr 2010 17:35:15 GMT

A getter method is to get one attribute, so declaring a functional method is sufficient (SAP also automatically creates these methods with RETURNING in persistent classes).

Or maybe you want to do something else than just a getter method?

Re: Getters Methods - Exporting vs Returning value()

FabioPagoti — Mon, 05 Apr 2010 18:16:46 GMT

Hello Sandra.. thanks for your help

in fact i really need get methods, but the problem is that some attributes which need to be returned are tables. The addition RETURNING cannot be used with generic types.

Re: Getters Methods - Exporting vs Returning value()

MarcinPciak — Mon, 05 Apr 2010 19:32:18 GMT

In my opinion functional method is better choice, for the following reasons:

- can be used inline (i.e. as an operand of IF...ENDIF block)

- you don't have to worry about initializing returning parameters, this is done in each method call. For exporting parameter you have to be very carefull, as they might be already passed to the method with some data in them. Althought it not recommended, it is doable, so before you call such method you have to pay atention to that.


If i use 'exporting', i'm just able to call the method using 'call method' keywords.

This is untrue. You can call it like


ref->method( exporting ....
                      changing .... ).

So the same way as you would call functional method, but you MUST determine whether is exporting/changing/imporitng parameter unless there are only importing parameters. In this case you can even skip the input/output signature.


If i use 'returning value', i have a functional method but its parameters must be fully specified.

Not sure now, but I think you could pass reference to data object (type ref to DATA) and deference it outside the method typing it respectively. I cannot however confirm this right now (no access to system) so here I may mistake. Try it out though.

Regards

Marcin

Re: Getters Methods - Exporting vs Returning value()

Former Member — Tue, 06 Apr 2010 09:28:14 GMT

Halo Fabio,

The addition RETURNING cannot be used with generic types. is wrong . You can declare a generic type (type ref to data ) in your class . You can use that generic type as your retruning parameter type.

For eg .


  methods get_records_to_be_displayed
  abstract
    returning
      value(rt_records_to_display) type tt_refdata .
Here tt_refdata is type ref to  DATA

Re: Getters Methods - Exporting vs Returning value()

franois_henrotte — Wed, 07 Apr 2010 14:28:15 GMT

a getter method MUST have a returning parameter

if you use a EXPORTING parameter then it is not a getter anymore !

it could seem to be not so bad to use EXPORTING, but then when you will use advanced techniques (like WebUI in CRM, just an example) it will not work if you don't respect this principle

a lot of standard classes in BOL (Business Object Layer) do rely on type of parameters in method signature...

Re: Getters Methods - Exporting vs Returning value()

RichHeilman — Wed, 07 Apr 2010 14:58:44 GMT

I am a fan of returning parameters for GET methods as well. I think it is a cleaner syntax.

this_value = this_object->get_this_value( ).

Another advantage in using returning parameters is when using method chaining, which will be available in NW 7.02( which is NW 7.0 enhancement pack 2 ). THis is coming later this year. Basically, for functional methods, one which return exactly one return parameter, you can chain method calls together. Like this.

this_object->do_something(  another_object->get_value( ) ).

In the above code, the GET_VALUE method returns a value which is then passed to the importing parameter of the DO_SOMETHING method.

Of course, this type of thing has been supported by other langauges for years, but is only coming to ABAP now.

Regards,

Rich Heilman

Edited by: Rich Heilman on Apr 7, 2010 10:59 AM

Re: Getters Methods - Exporting vs Returning value()

naimesh_patel — Wed, 07 Apr 2010 15:45:25 GMT

One more point to add: Returning always use the Pass by Value where as with Exporting you can decide if you want pass by value of reference. From encapsulation purpose, we should always use the Pass by Value.

Regards,

Naimesh Patel

Re: Getters Methods - Exporting vs Returning value()

MarcinPciak — Wed, 07 Apr 2010 16:35:09 GMT


Another advantage in using returning parameters is when using method chaining, which will be available in NW 7.02( which is NW 7.0 enhancement pack 2 ).

Finally! Anxiously awaiting this

Regards

Marcin

Re: Getters Methods - Exporting vs Returning value()

Former Member — Wed, 07 Apr 2010 21:04:23 GMT

Hi Rich,

Your example on [method chaining|http://en.wikipedia.org/wiki/Method_chaining] is slightly off as you are not chaining methods, but merely use the result of another method as an input parameter (instead of invoking a method on the returned object of the first method call). Here's and example from the ABAP help for [method chaining|http://help.sap.com/abapdocu_70/en/ABENFUNCTIONS_EXPRESSIONS.htm].

Anyhow, for me you're touching a really sore point in ABAP though. The possibility to use expressions in statements (e.g. IF) was missing far too long and only with release 7.0 EHP 2 we seem to get this.

Maybe they even provide boolean's at some point (meaning variables that can be assigned the result of a logical expression). I'd be more than happy if somebody would point out to me that this feature already exists...

As far as the getter/setter discussion I agree with the others that true getter/setter methods by definition should only use a returning parameter. After all, they are just a crutch (awkward syntax, code bloat) for encapsulating access to attributes (might be calculated) and thus should only return one object/value. On my wish list though would be the shorter and more flexible syntax like Scala setters and getters or .NET properties.

Cheers, harald

Re: Getters Methods - Exporting vs Returning value()

RichHeilman — Wed, 07 Apr 2010 21:56:07 GMT

Hi Harold, thanks for pointing out that my term, "method chaining" and my example, don't necessarily sync up. I have a habit of using the term method chaining to describe both my example, and the one you see in the help document. I need to learn to use the term "enhanced expressions" when referring to my example code. Thanks for the clarification. Also, I feel your pain about certain ABAP syntax being missing for far too long. But I have say that I feel pretty good about the new investments into the ABAP language and tool set. SAP is investing heavy in these areas, and some very cool things are coming. So stay tuned.

Regards,

Rich Heilman

Re: Getters Methods - Exporting vs Returning value()

Former Member — Wed, 07 Apr 2010 22:19:08 GMT

Thanks for the update, Rich. The new language features look good, my main issue is that at clients we're more often using older releases and all those nice features are not available.

Anyhow, I actually wanted to edit my posting to fix my poor mistake of mentioning setters and returning parameters - not sure where my brain was, when typing this...