Split method instead of Boolean input parameter

[sap]

Split method instead of Boolean input parameter

[HrFlorianHoffmann]

Really?

METHOD update_and_save.
  update_without_saving( ).
  COMMIT WORK.
ENDMETHOD.

Splitting into update and save cuts a different seam, leading to a different pattern for the consumer:

update( ).
save( ).

May also be valid of course, but not what the example set out to demonstrate. :-)

[f4abap]

No.. it's exact the same example, just the wording is clearer.
METHOD save.
update( ).
COMMIT WORK.
ENDMETHOD.

With the enhanced example here I got more problems than before. That mean you would code the update table ... into the method and just hope, that there will not be an implicit commit.
So maybe it's complete wrong.

update_internal( ).
update_db( ).

--> then it makes also sense when there is this inside:

METHOD update_db.
  update_internal( ).
UPDATE TABLE ... from whatever.
COMMIT WORK.
ENDMETHOD.

[HrFlorianHoffmann]

I'd still not say there is something "wrong" with any of these examples. It just sounds like we have different ideas of what the terms "update" and "save" mean, and what the overall structure of the code could be. :-)

A more complete example could be:

" public
METHOD modify_db_without_comitting.
  modify_db( ).
ENDMETHOD.

" public
METHOD modify_db_and_commit.
  modify_db( ).
  commit( ).
ENDMETHOD.

" private
METHOD modify_db.
  MODIFY <db_table> FROM <member_attribute>.
ENDMETHOD.

" private
METHOD commit.
  COMMIT WORK.
ENDMETHOD.

There are three prevalent cases for Boolean input parameters:

• a. To set a Boolean attribute. In this case, the Boolean input is fine.
• b. To choose a fully alternative implementation of the method.
• c. To switch on an additional side feature within the method, like in the example here.

Should we try and find a suitable case b. example to avoid the kind of misunderstandings with case c. examples we see here?

[rdibbern]

The community has not responded to @HrFlorianHoffmann proposals