What are the OOP best practice guidelines - in general or specific for ABAP - for using attributes to store data versus just passing it along as method parameters.

I'm having a hard time deciding when to do what and am also interested to learn more in terms of correct OO Modeling.


New contributor
Christian B. is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 1
    Sharing your research helps everyone. Tell us what you've tried and why it didn't meet your needs. This demonstrates that you've taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat Mar 26 at 8:20
  • 2
    (I noticed you were given a poor advice at Stack Overflow - sorry about that) – gnat Mar 26 at 8:22

In programming, we build abstractions representing domain concepts.  Ideally, we make things easier for the consuming client programmer (often ourselves).  Coherent abstractions help with that.  One way to look coherence of an abstraction is to look at the lifetime of its members.

Our abstractions are often compositions, objects with multiple fields.  Sometimes we compose things that don't belong together — that should really be separate objects, and, other times we fail to compose things that are logically one object.

One way to inspect coherence is to look at the lifetimes of our compositions and objects.  Things that have the same lifetime are often good candidates for being together in an abstraction, and things that don't are often good candidates for being separate.

If we have an object being created and only some of its fields are meaningfully initialized and initially relevant, while other of its fields have a shorter, temporary lifetime, are used only by certain methods, e.g. to interchange data, this suggests that we have over used composition, and, we should consider separating fields out into two or more different entities by their shared lifetimes.

If we make the consuming client programmer pair two (or more) of entities, and these pairs have the same lifetime, it suggests we have failed to identify an abstraction — one that binds together the pair, and should consider composing these pairs into a single abstraction for the consuming client programmer to deal with.

Further reading:

Is it acceptable to assign a class variable within a method?

Should one create shareable private class member or keep variable in method scope to pass it as a second method argument?

|improve this answer|||||

(My opinion on this.) I don't think that there is a "categorical" answer ... and I think that your question as posed either wishes or assumes that there is one.

"Method parameters" don't store data: they are simply inputs, needed by the method to carry out a particular operation. If some client of the object wants to make a series of independent calls using the same values, "that's his business, not ours."

On the other hand, if a particular piece of data logically does "belong to" or "belong with" a particular object instance, it should be stored with it. And, if one method-call somehow "changes the behavior of future method calls" ... if it "changes the internal state of the object instance" ... then of course the values which determine this should be public or private attributes of the object.

However, these are merely rules of thumb.

|improve this answer|||||

Your Answer

Christian B. is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.