appropriate class variable usage?

[not_a_commie]

I'm working on some legacy code that passes variables to other methods
in a class via class variables rather than parameters on the method.
This seems like bad practice to me, especially from a multithreaded
standpoint. I recognize that there are some situations where some
class state needs to be stored in class variables, but requiring that
properties or methods be called in a specific order also seems wrong.
It does seem appropriate to store references to dependent services
that came in on the constructor in class variables.

Does anyone know of any good books or articles that review appropriate
uses of class variables? (Especially from a Java or C# perspective?)

 

[Arne Vajhøj]

I'm working on some legacy code that passes variables to other methods
in a class via class variables rather than parameters on the method.
This seems like bad practice to me, especially from a multithreaded
standpoint. I recognize that there are some situations where some
class state needs to be stored in class variables, but requiring that
properties or methods be called in a specific order also seems wrong.
It does seem appropriate to store references to dependent services
that came in on the constructor in class variables.

Does anyone know of any good books or articles that review appropriate
uses of class variables? (Especially from a Java or C# perspective?)

OO attempts to model the real world.

Lots of things in the real world has state, so many
classes have state.

It does create some dependencies between calls, but if
everything is modeled properly then those dependencies
reflect real world dependencies.

Arne

 

[Peter Duniho]

I'm working on some legacy code that passes variables to other methods
in a class via class variables rather than parameters on the method.
This seems like bad practice to me, especially from a multithreaded
standpoint. I recognize that there are some situations where some
class state needs to be stored in class variables, but requiring that
properties or methods be called in a specific order also seems wrong.
It does seem appropriate to store references to dependent services
that came in on the constructor in class variables.

Does anyone know of any good books or articles that review appropriate
uses of class variables? (Especially from a Java or C# perspective?)

Sorry, I don't know of a specific resource for that kind of discussion.

As for the general practice, without seeing the code, it's impossible to
know whether it's a good or bad design. In general, I'd agree that if
the data is _only_ the equivalent to arguments passed to a method — that
is, is used only for the single method call — then having the data
initialized in the class before the method call is inferior design.

And if the data is literally being passed by assignment to member
instance variables of a class, and those variables are public, well…the
mere presence of public member variables in a class is definitely a bad
idea. At the very least, they ought to be wrapped up in properties.

But as Arne says, sometimes you are trying to model something that
actually has some kind of stateful behavior where it makes sense to set
up some state prior to a method call. And in other cases, it's simply
more expedient or a more usable API to do it that way.

For example, the Thread and (especially) Process classes, where you
create an object that is only partially initialized and which requires
some additional initialization before initiating the object's real job.
(Though, I wonder if C# had optional arguments from the outset whether
these types would have been designed that way).

Some of the time, it just doesn't work to pass data needed by a method
as an actual argument to that method. In those cases, it should be fine
or even desirable to pre-initialize the class before calling a method
(of course, the class should have checks to enforce the
pre-initialization, if required).

The general rule is "pass method arguments as method arguments, not
instance or static data". But as with all rules, the art is in knowing
when the rule does not apply.

Pete