Member variables as private method arguments

[David Veeneman]

Should a member variable be passed to a private method in the same class as
a method argument, or should the method simply call the member variable?

For years, I have passed member variables to private methods in the same
class as method arguments. For example, if Public method Foo() calls private
method Bar(), and if Bar() uses member variable m_MyVariable, I declare the
private method with the signature:

private void Bar(SomeType myVariable)
{
...
}

Foo() calls Bar() as:

this.Bar(m_MyVariable);

In other words, even though Bar() could call m_MyVariable directly, I don't
do it. Instead, I create a local variable within Bar() to hold the value.

I've done this to keep my private methods as self-contained as possible, and
to make it obvious from the method signature just what the method needs in
order to do its job. Arguably, this approach makes it easier to follow the
flow of control within the program.

But now I'm not so sure it's such a good idea. I often end up with long
method signatures with a half-dozen or more arguments, and I find that I'm
passing the same member variables (typically helper objects) to every
private method in a class.

So, what do you think? Am I better off passing member variables to private
methods as arguments, or should I simply let the methods call member
variables directly? Thanks for your input.

David Veeneman
Foresight Systems

 

[VJ]

Interesting.. I am on the other side, everything goes property side and even
my public methods I eliminate parameters. Well of the top I have no idea if
there are disadvantages or advantages to both. Yes code readability and
containment is one possiblity. If you have long method signatures, some
people say that is not good. This is interesting thread, will see what the
experts post.!!

VJ

 

[Oliver Sturm]

Hello David,

For me personally, I believe that if my OO structure is good, I shouldn't
have to pass in parameters to methods in my classes that duplicate
information that is already stored in the class's fields. Now if the class
has a lot of fields and methods, I might reach the point where I want to
refactor things to break down what the class does - this involves
extracting fields and related behaviour into other classes, and it will
arguably be easier to do that if my methods have parameter lists that make
it clear with and on which information they work. So following this
procedural train of thought makes me move in circles, in a way...

Still. I understand what you have in mind with the long parameter lists
and passing in and out duplicate information, and I agree there are
advantages in certain cases. But my preference is to have instance methods
of classes work on the members of those classes directly, and to interpret
growing complexity of the classes as well as the methods as a signal for
the necessity to refactor and restructure. Of course, there are always
methods that don't work directly with information that is also stored in
fields of the class, so in these cases I would naturally use parameters.


Oliver Sturm

 

[David Veeneman]

Response unanimously recommended against passing paramters--not OO. I'm
convinced. Thanks for your help.

 

[David Veeneman]

Good point, and I'm convinced. Thanks for your helo!

 

[RobinS]

Isn't it great when people confirm that you should do what you really want
to do but are afraid it's not the right way?

Robin S.
p.s. For the record, I agree with the other responses.

 

[Peter Duniho]

Should a member variable be passed to a private method in the same class
as a method argument, or should the method simply call the member
variable?

You seem to already have received the answer you want. But I'll just
point out that it's not an either/or thing.

If you want a method to always operate on the same member variable of the
class then I agree, passing as a parameter is a waste. However, sometimes
you'll have a method within a class that is more general purpose and may
be used on a variety of member variables (or perhaps even a variable from
somewhere else, like a local variable). In those cases, passing as a
parameter is more appropriate (and of course, the only practical way ).

Also, one might argue that the method you present as an example has the
advantage that the method is somewhat more self-documenting. That is, if
you intend to change the member variable then you'll use the "ref" or
"out" keywords (depending on how the member variable is used), and it
makes it a little more obvious what side-effect the method has in that
case. But of course you could simply just document that behavior with a
comment and hope that you or someone else looking at the code remember to
read the comment. It's not clear to me that the self-documenting
advantage is justification for passing a member variable as a parameter
when the method always operates on the same member variable, but I accept
that some programmers may weigh the choices differently.

Probably the biggest problem with passing member variables comes up with
you absolutely intend the method to *only* be used with a particular
member variable. In that case, offering a parameter may encourage someone
(you or someone else, depending on who's maintaining the code) to use the
method inappropriate by passing some other value.

As you can see, the answer really is "it depends".

Pete

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

To add a bit to what has already been said:

Passing parameters instead of using global variables was a good practice
before object orientation, but that is no longer needed as the variables
are no longer global.

Methods of a class is expected to use the members of the class.
Actually, if you are creating a method that doesn't use any members of
the class but only the parameters, you should make the method static, so
that it's obvious that it's independent.

 

[Bruce Wood]

To add a bit to what has already been said:

Passing parameters instead of using global variables was a good practice
before object orientation, but that is no longer needed as the variables
are no longer global.

I agree with you generally speaking, but I disagree with this as a
hard-and-fast rule. All O-O did was make truly global variables almost
extinct, and moved the scope of "global" data into a class definition.

Some classes are quite complicated, and contain a lot of data. In such
cases, there _is_ value in creating private methods that are clearly
marked as not needing the entire state of the object in order to do
their work. This can be valuable because one can immediately see by
looking at the method that it needs only two or three pieces of the
object's state in order to function. It is no longer necessary to read
the method's code (and the code of everything it calls) in order to
know for sure what parts of the object's state it reads, and what
parts it alters.

In other words, it's the old problem of global variables in-the-small:
the class's fields become the "global variables" if you will.

However, the OP's original idea was extreme, IMHO. Once you end up
with more than a handful of items being passed to a private "helper"
method, or once you end up with "ref" or "out" parameters because the
method alters more than one field in the object's state, then IMHO
it's time to drop the parameters and just make the thing a
parameterless method that works directly on the object's state.

As well, in order that this have value, the class has to have a large
number of fields. If the thing has only five or six fields, then
making a private method static in order to demonstrate that it needs
only two of them is overkill.

Actually, if you are creating a method that doesn't use any members of
the class but only the parameters, you should make the method static, so
that it's obvious that it's independent.

Absolutely. You stole my thunder on this point. Yes, it is helpful to
make some methods "independent" of object state by passing what they
need as parameters. However, if you're going to do that then you
should always make the method static. Otherwise you're missing out on
a great opportunity to clearly "promise" to the reader that the method
neither reads nor writes any more of the object's state than the
parameters that you've provided. A private _instance_ method that has
everything passed to it is nothing more than a code bomb: someday
someone is going to "tweak" it to read or write some object state
directly (because it's easier than changing its parameter list), or
change it to call some other method that in turn reads the object's
state, and then the advantage of passing arguments--that it clearly
indicates what the method works on--is not only lost, but misleading.

If you're going to pass it everything it needs--and that's often
valuable--then it should be static.