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.
Cheers
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?
(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.
