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