Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Suppose within the private portion of a class there is a value which is utilized by multiple private methods. Do people prefer having this defined as a member variable for the class or passing it as an argument to each of the methods - and why?

On one hand I could see an argument to be made that reducing state (ie member variables) in a class is generally a good thing, although if the same value is being repeatedly used throughout a class' methods it seems like that would be an ideal candidate for representation as state for the class to make the code visibly cleaner if nothing else.

Edit:

To clarify some of the comments/questions that were raised, I'm not talking about constants and this isn't relating to any particular case rather just a hypothetical that I was talking to some other people about.

Ignoring the OOP angle for a moment, the particular use case that I had in mind was the following (assume pass by reference just to make the pseudocode cleaner)

int x
doSomething(x)
doAnotherThing(x)
doYetAnotherThing(x)
doSomethingElse(x)

So what I mean is that there's some variable that is common between multiple functions - in the case I had in mind it was due to chaining of smaller functions. In an OOP system, if these were all methods of a class (say due to refactoring via extracting methods from a large method), that variable could be passed around them all or it could be a class member.

share|improve this question
1  
How is this value used? It is constant? Does it change? Is it subject to changes between compilations? –  Oded Sep 27 '11 at 21:30
    
When things are automatically determine to be all the same, it's easier to think that it doesn't matter. What if you had a function that needed an adjusted (x) value like x-1 ? –  JeffO Jun 10 at 12:59
add comment

6 Answers

If the value is a property of the class, keep it in the class, otherwise, keep it outside. You don't design your class methods-first, you design its properties first. If you did not think of putting that property inside the class in the first place, there is probably a reason for that.

The worst thing you can do, in terms of scalability, is changing your code for convenience. Sooner rather than later you'll find your code is bloated and duplicated. However I must admit sometimes I break this rule... Convenience is just so damn appealing.

share|improve this answer
1  
I agree - the original design/purpose of the class should tell you whether it should be a member variable or an argument. Also worth thinking about the dependency injection angle. –  Martijn Verburg Sep 27 '11 at 21:49
add comment

If you don't actually need to hold the state between invocations (and apparently you don't, or you wouldn't ask the question) then I would prefer the value be an argument, rather than a member variable, because a quick glance at the method's signature tells you that it uses the argument, while it's a little harder to tell right away what member variables are used by the method. It is also not always quick to determine what private member variables are for.

So normally I wouldn't agree that code using member variables is visibly cleaner, but if the method signatures are getting out of hand I might make an exception. It's a worthwhile question, but not something the project will hinge on in any case.

share|improve this answer
add comment

if the value does not change, it is by definition a constant and should be encapsulated inside the class. In such case, it is not considered to affect the state of an object. I don't know your case but I think of something such as PI in trigonometry. If you try to pass an argument of such a constant, you could be exposing the result to error if the client passes the wrong value or a value not with the same accuracy as the method(s) expect.

share|improve this answer
add comment

Perhaps you should extract a new class containing all the methods sharing that value. Of course the highest-level method will be public in the new class. It may be helpful to expose that method for testing.

If you have two or more temporaries that are always passed together, then you should almost certainly extract a new class.

share|improve this answer
add comment

Do people prefer having this defined as a member variable for the class or passing it as an argument to each of the methods - and why?

If I understand what you're asking: The methods in a class are by definition privy to the implementation details, so I'd have no qualms about using any member directly from any method.

On one hand I could see an argument to be made that reducing state (ie member variables) in a class is generally a good thing...

There's nothing wrong with declaring a private static final to define constants. The compiler will be able to use the value in considering some optimizations, and being constants, they don't really add state to the class.

although if the same value is being repeatedly used throughout a class' methods...

Being able to refer to it symbolically (e.g., BLRFL_DURATION) and not having to add extra arguments to your methods will make your code more readable and therefore more maintainable.

share|improve this answer
add comment

Thanks for asking the question, I wanted to ask this also.

When I was thinking about this, there are some advantages in why to pass it as argument

  • it's easier to test -> easier to maintain (related to last point)
  • has no side effects
  • it's easier to understand

I clearly see your point for example - one is parsing Excel document (using POI library for example) and instead of passing row instance to every method that needs to work with that row, author has member variable currentRow and works with it.

I'd say there should be a name for this anti-pattern, is it? (not listed here)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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