views:

515

answers:

5

How do you guys decide between keeping track of something locally and then just passing it in to every method you call on it, or declaring an instance variable and using it in the methods?

I tend to prefer instance variables kept in a list at the end of the Class. But as my programs become more and more complicated, this list gets longer and longer... I figure that if something is getting passed often enough it should just be visible to all the boys and girls who need it, but then I start wondering, "why not just make everything public! Then there will be no more need of passing anything at all!"

+7  A: 

Mainly this depends on the lifetime of the data you store in the variable. If the data is only used during a computation, pass it as a parameter. If the data is bound to the lifetime of the object use an instance variable.

When your list of variables gets too long, maybe it's a good point to think about refactoring some parts of the class into a new class.

H-Man2
+2  A: 

Of course it is easy to keep one big list of public variables in the class. But even intuitively, you can tell that this is not the way to go.

Define each variable right before you are going to use it. If a variable supports the function of a specific method, use it only in the scope of the method.

Also think about security, a public class variable is susceptible to unwanted changes from "outside" code. Your main goal should be to keep all variables private, and any variable which is not, should have a very good reason to be so.

About passing parameters all they way up the stack, this can get ugly very fast. A rule of thumb is to keep your method signatures clean and elegant. If you see many methods using the same data, decide either if it's important enough to be a class member, and if it's not, refactor your code to have it make more sense.

It boils down to common sense. Think exactly where and why you are declaring each new variable, what it's function should be, and from there make a decision regarding which scope it should live in.

Yuval A
+2  A: 

IMHO:

If the variable forms part of the state of the instance, then it should be an instance variable - classinstance HAS-A instancevariable.

If I found myself passing something repeatedly into an instance's methods, or I found that I had a large number of instance variables I'd probably try and look at my design in case I'd missed something or made a bad abstraction somewhere.

Hope it helps

Brabster
+11  A: 

Since you're referring to instance variables, I'm assuming that you're working in an object-oriented language. To some degree, when to use instance variables, how to define their scope, and when to use local variables is subjective, but there are a couple of rules of thumb you can follow whenever creating your classes.

  • Instance variables are typically considered to be attributes of a class. Think of these as adjectives of the object that will be created from your class. If your instance data can be used to help describe the object, then it's probably safe to bet it's a good choice for instance data.

  • Local variables are used within the scope of methods to help them complete their work. Usually, a method should have a purpose of getting some data, returning some data, and/or proccessing/running an algorithm on some data. Sometimes, it helps to think of local variables as ways of helping a method get from beginning to end.

  • Instance variable scope is not just for security, but for encapsulation, as well. Don't assume that the "goal should be to keep all variables private." In cases of inheritance, making variables as protected is usually a good alternative. Rather than marking all instance data public, you create getters/setters for those that need to be accessed to the outside world. Don't make them all available - only the ones you need. This will come throughout the development lifecycle - it's hard to guess from the get go.

When it comes to passing data around a class, it's difficult to say what you're doing is good practice without seeing some code . Sometimes, operating directly on the instance data is fine; other times, it's not. In my opinion, this is something that comes with experience - you'll develop some intuition as your object-oriented thinking skills improve.

Tom
My answer would be adding this answer to H-Man2 answer (lifetime). It should be a member attribute if and only if it is a persistent state of the object. That is, the value makes sense by itself outside of the scope of the current method stack.
David Rodríguez - dribeas
+2  A: 

In my opinion, instance variables are only necessary when the data will be used across calls.

Here's an example:

myCircle = myDrawing.drawCircle(center, radius);

Now lets imaging the myDrawing class uses 15 helper functions to create the myCircle object and each of those functions will need the center and the radius. They should still not be set as instance variables of the myDrawing class. Because they will never be needed again.

On the other hand, the myCircle class will need to store both the center and radius as instance variables.

myCircle.move(newCenter);
myCircle.resize(newRadius);

In order for the myCircle object to know what it's radius and center are when these new calls are made, they need to be stored as instance variables, not just passed to the functions that need them.

So basically, instance variables are a way to save the "state" of an object. If a variable is not necessary to know the state of an object, then it shouldn't be an instance variable.

And as for making everything public. It might make your life easier in the moment. But it will come back to haunt you. Pease don't.

ng.mangine
this was very helpful!
Ziggy