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: 

Should the CHANGE parameter type be used?

frank_stdle
Participant
0 Kudos

I'm working on some legacy code and seeing extensive use of the "changing" type of parameters -- structures are passed on to methods and modified. Should changing parameters be used in a modern programming language? Does it not violate command-query separation? To me it just seems messy to pool the input parameters and output parameters into one lump - are there any good cases for using "changing"? 

1 ACCEPTED SOLUTION

naimesh_patel
Active Contributor
0 Kudos

Command-Query separation would be violated even when you use Export and Import, Export and Returning in the same method call. As per this principle, your method should be either Command or Query. This principle is not that helpful as it increases the burden on design to segregate simple operations into multiple Commands & Queries.

To make life simpler for Caller - which would be ideal for any software - you wrap those multiple commands & queries in single call which would have again Exporting, Importing, Changing or Returning parameters. So, it would be a judgement call to decide to violate Command-Query or to implement different design patterns.


8 REPLIES 8

former_member223537
Active Contributor
0 Kudos

Hi Frank,

Well if you are talking about subroutines which have USING, CHANGING parameters , then yes it can be used in modern programming rather than using a global variable you can do away with local variables.

Same is with Function Module - TABLES is obsolete in ECC 6.0, so CHANGING is to be used.

The same is applicable for Methods as well.

Thanks,

Best regards,

Prashant

0 Kudos

I am talking about ABAP OO - subroutines ("FORM") are deprecated, and functions modules should be avoided as well.

0 Kudos

Hi

In ABAP OO its Importing,Exporting,Changing & Receiving. Each has its own importance.

Now if you are passing a value to be changed through changing parameter. It might change or may not change by the logic written inside the method, but the user intention is to just use the value in this parameter in the proceeding step( passed value to the method or the changed value from the method). This cannot be done through other options. Please read sap help for "changing" parameter to get more insight.

"Does it not violate command-query separation" - What makes you think like this

naimesh_patel
Active Contributor
0 Kudos

Command-Query separation would be violated even when you use Export and Import, Export and Returning in the same method call. As per this principle, your method should be either Command or Query. This principle is not that helpful as it increases the burden on design to segregate simple operations into multiple Commands & Queries.

To make life simpler for Caller - which would be ideal for any software - you wrap those multiple commands & queries in single call which would have again Exporting, Importing, Changing or Returning parameters. So, it would be a judgement call to decide to violate Command-Query or to implement different design patterns.


0 Kudos

Naimesh Patel wrote:

Command-Query separation would be violated even when you use Export and Import, Export and Returning in the same method call.

I agree. Just seems to me that CHANGING is even worse - there's now way to know what will be changed and even if it will be changed. I think perhaps CHANGING parameter was inherited from function modules just to make OO methods look more familiar to ABAPers.

0 Kudos

Agree. I'm not sure what was the reason behind to have CHANGING parameter in the method signature.

Frank Stødle wrote:

I think perhaps CHANGING parameter was inherited from function modules just to make OO methods look more familiar to ABAPers.

The CHANGING parameters are used heavily when working with the Internal Tables. Like methods GUI_UPLOAD, GUI_DOWNLOAD for classes CL_GUI_FRONTEND_SERVICES.  Which are kind of replacement of the FMs. So, by having the CHANGING parameters its easy replacement of FM by the Method call. Without Changing, there would be two methods, one to read data into temp table and second to get that from that temp table while honoring the Command-Query Separation.

0 Kudos

Hello Frank,

I think CHANGING parameters in ABAP are similar to IN/OUT parameters of other programming languages (viz., C++) and have got nothing to do with legacy FMs in ABAP.

One of the proper usages of CHANGING params is in the custom controller driven ALV grid display method CL_GUI_ALV_GRID->SET_TABLE_FOR_FIRST_DISPLAY( ). The driver table has to be passed as CHANGING because different ALV operations (Sorting, Filtering etc.) change the content of the table.

As already mentioned the kind of param has to be used in your procedure depends completely on your requirement.

BR,

Suhas

PS: I remember having read a blog by Volker Wegert highlighting some typing issues with CHANGING params. Not able to search it in new SCN

0 Kudos

I guess, you are referring to this blog post:  http://scn.sap.com/people/volker.wegert2/blog/2011/03/25/abap-trapdoors-morphing-method-parameters

Regards,
Naimesh Patel