While coding a function in a class that is supposed to be instantiated, some variables are used only temporarily - e.g. as a counter in a for loop - some are globals and others are returned and/or "stored" in the object's instance as instance.variable, instance->variable... depending on the syntax.
My question is, should I always use object.variable = when defining a variable in said function, or should I only use it if I intend to return it or make it available for the user?
I'm no professional so I'm not sure if I'm looking at it the right way, but from where I see it there are a few reasons why I should use one or the other, as well as some advantages and disadvantages on always using object.variable:
variable
If the scope should be only the function where it is defined, OR
If it's a global (and obviously not unique to each instance).
object.variable:
If it should be accessible for another method or for the user.
If it should be unique to each instance.
And
It's always accessible within the scope you set it, eliminating possible scope issues.
It may have security implications.
Am I looking at this the right way?
You use the term 'variable' to designate three distinct notions:
A variable declared in a function is a local variable;
A variable declared in a class is a member attribute, or an
instance variable;
A variable declared in a class (and static) is a class variable.
A local variable is accessible only from the block in which it is declared, be it a condition, a loop or a function. Your loop counter variable should be local, because you won't use it elsewhere. Plus, it can't be an attribute because it has nothing to do with your instance.
Use: variable
A member attribute is a property bound to the instance. It characterizes it. Thus it is not available (and doesn't exist in memory) until you instantiate the object. It is declared inside the class, but outside of any method. You also have to precise it's visibility (public, protected, private). See encapsulation.
Never mark a member public unless you have a good reason to.
A public member (be it a property or a method) can be accessed this way outside of a class:
MyObject obj = new MyObject();
obj.myMethod();
When you want to use it inside your class, from one of your method, for instance, you can use variable. However, using this.variable is a good practice: It is possible to declare a local variable with the same name as an attribute. It could become a real nightmare if you don't stick to this habit. Note that the this keyword may differ depending on which language you work with.
A class variable/method exists independently of any instances created. It exists before you ever make a new instance. There will be only one copy, regardless of how many instances of the class exist. Just as instance member, you have to set a visibility.
It is a good practice to use MyClass.member, be it inside or outside the class.
I hope that answers your question.
Related
I am from a C# background and have been doing programming for quite some time now. But only recently i started giving some thoughts on how i program. Apparently, my OOP is very bad.
I have a few questions maybe someone can help me out. They are basic but i want to confirm.
1- In C#, we can declare class properties like
private int _test;
and there setter getters like
public int Test {get; set;}
Now, lets say i have to use this property inside the class. Which one will i use ? the private one or the public one ? or they both are the same ?
2- Lets say that i have to implement a class that does XML Parsing. There can be different things that we can use as input for the class like "FILE PATH". Should i make this a class PROPERTY or should i just pass it as an argument to a public function in the class ? Which approach is better. Check the following
I can create a class property and use like this
public string FilePath {get; set;}
public int Parse()
{
var document = XDocument.Load(this.FilePath);
.........//Remaining code
}
Or
I can pass the filepath as a parameter
public int Parse(string filePath)
On what basis should i make a decision that i should make a property or i should pass something as argument ?
I know the solutions of these questions but i want to know the correct approach. If you can recommend some video lectures or books that will be nice also.
Fields vs Properties
Seems like you've got a few terms confused.
private int _test;
This is an instance field (also called member).
This field will allow direct access to the value from inside the class.
Note that I said "inside the class". Because it is private, it is not accessible from outside the class. This is important to preserve encapsulation, a cornerstone of OOP. Encapsulation basically tells us that instance members can't be accessed directly outside the class.
For this reason we make the member private and provide methods that "set" and "get" the variable (at least: in Java this is the way). These methods are exposed to the outside world and force whoever is using your class to go trough your methods instead of accessing your variable directly.
It should be noted that you also want to use your methods/properties when you're inside the current class. Each time you don't, you risk bypassing validation rules. Play it safe and always use the methods instead of the backing field.
The netto result from this is that you can force your logic to be applied to changes (set) or retrieval (get). The best example is validation: by forcing people to use your method, your validation logic will be applied before (possibly) setting a field to a new value.
public int Test {get; set;}
This is an automatically implemented property. A property is crudely spoken an easier way of using get/set methods.
Behind the scenes, your code translates to
private int _somevariableyoudontknow;
public void setTest(int t){
this._somevariableyoudontknow = t;
}
public int getTest(){
return this._somevariableyoudontknow;
}
So it is really very much alike to getters and setters. What's so nice about properties is that you can define on one line the things you'd do in 7 lines, while still maintaining all the possibilities from explicit getters and setters.
Where is my validation logic, you ask?
In order to add validation logic, you have to create a custom implemented property.
The syntax looks like this:
private int _iChoseThisName;
public int Test {
get {
return _iChoseThisName;
}
set {
if(value > 5) { return _iChoseThisName; }
throw new ArgumentException("Value must be over 5!");
}
}
Basically all we did was provide an implementation for your get and set. Notice the value keyword!
Properties can be used as such:
var result = SomeClass.Test; // returns the value from the 'Test' property
SomeClass.Test = 10; // sets the value of the 'Test' property
Last small note: just because you have a property named Test, does not mean the backing variable is named test or _test. The compiler will generate a variablename for you that serves as the backing field in a manner that you will never have duplication.
XML Parsing
If you want your second answer answered, you're going to have to show how your current architecture looks.
It shouldn't be necessary though: it makes most sense to pass it as a parameter with your constructor. You should just create a new XmlParser (random name) object for each file you want to parse. Once you're parsing, you don't want to change the file location.
If you do want this: create a method that does the parsing and let it take the filename as a parameter, that way you still keep it in one call.
You don't want to create a property for the simple reason that you might forget to both set the property and call the parse method.
There are really two questions wrapped in your first question.
1) Should I use getters and setters (Accessors and Mutators) to access a member variable.
The answer depends on whether the implementation of the variable is likely to change. In some cases, the interface type (the type returned by the getter, and set by the setter) needs to be kept consistent but the underlying mechanism for storing the data may change. For instance, the type of the property may be a String but in fact the data is stored in a portion of a much larger String and the getter extracts that portion of the String and returns it to the user.
2) What visibility should I give a property?
Visibility is entirely dependent on use. If the property needs to be accessible to other classes or to classes that inherit from the base class then the property needs to be public or protected.
I never expose implementation to external concerns. Which is to say I always put a getter and setter on public and protected data because it helps me ensure that I will keep the interface the same even if the underlying implementation changes. Another common issue with external changes is that I want a chance to intercept an outside user's attempt to modify a property, maybe to prevent it, but more likely to keep the objects state in a good or safe state. This is especially important for cached values that may be exposed as properties. Think of a property that sums the contents of an array of values. You don't want to recalculate the value every time it is referenced so you need to be certain that the setter for the elements in the array tells the object that the sum needs to be recalculated. This way you keep the calculation to a minimum.
I think the second question is: When do I make a value that I could pass in to a constructor public?
It depends on what the value is used for. I generally think that there are two distinct types of variables passed in to constructors. Those that assist in the creation of the object (your XML file path is a good example of this) and those that are passed in because the object is going to be responsible for their management. An example of this is in collections which you can often initialize the collection with an array.
I follow these guidelines.
If the value passed in can be changed without damaging the state of the object then it can be made into a property and publicly visible.
If changing the value passed in will damage the state of the object or redefine its identity then it should be left to the constructor to initialize the state and not be accesible again through property methods.
A lot of these terms are confusing because of the many different paradigms and languages in OO Design. The best place to learn about good practices in OO Design is to start with a good book on Patterns. While the so-called Gang of Four Book http://en.wikipedia.org/wiki/Design_Patterns was the standard for many years, there have since been many better books written.
Here are a couple resources on Design Patterns:
http://sourcemaking.com/design_patterns
http://www.oodesign.com/
And a couple on C# specific.
http://msdn.microsoft.com/en-us/magazine/cc301852.aspx
http://www.codeproject.com/Articles/572738/Building-an-application-using-design-patterns-and
I can possibly answer your first question. You asked "I have to use this property inside the class." That sounds to me like you need to use your private variable. The public method which you provided I believe will only do two things: Allow a client to set one of your private variables, or to allow a client to "see" (get) the private variable. But if you want to "use this property inside the class", the private variable is the one that should be your focus while working with the data within the class. Happy holidays :)
The following is my personal opinion based on my personal experience in various programming languages. I do not think that best practices are necessarily static for all projects.
When to use getters, when to use private instance variables directly
it depends.
You probably know that, but let's talk about why we usually want getters and setters instead of public instance variables: it allows us to aquire the full power of OOP.
While an instance variable is just some dump piece of memory (the amount of dumbness surely depends on the language you're working in), a getter is not bound to a specific memory location. The getter allows childs in the OOP hirarchy to override the behaviour of the "instance variable" without being bound to it. Thus, if you have an interface with various implementations, some may use ab instance variable, while others may use IO to fetch data from the network, calculate it from other values, etc.
Thus, getters do not necessarily return the instance variable (in some languages this is more complicated, such as c++ with the virtual keyword, but I'll try to be language-independent here).
Why is that related to the inner class behaviour? If you have a class with a non-final getter, the getter and the inner variable may return different values. Thus, if you need to be sure it is the inner value, use it directly. If you, however, rely on the "real" value, always use the getter.
If the getter is final or the language enforces the getter to be equal (and this case is way more common than the first case), I personally prefer accessing the private field directly; this makes code easy to read (imho) and does not yield any performance penalty (does not apply to all languages).
When to use parameters, when to use instance variables/properties
use parameters whereever possible.
Never use instance variables or properties as parameters. A method should be as self-contained as possible. In the example you stated, the parameterized version is way better imo.
Intance variables (with getters or not) are properties of the instance. As they are part of the instance, they should be logically bound to it.
Have a look at your example. If you hear the word XMLParser, what do you think about it? Do you think that a parser can only parse a single file it is bound to? Or do you think that a parser can parse any files? I tend to the last one (additionally, using an instance variable would additionally kill thread-safety).
Another example: You wish to create an XMLArchiver, taking multiple xml documents into a single archive. When implementing, you'd have the filename as a parameter of the constructor maybe opening an outputstream towards the file and storing a reference to it as an instance variable. Then, you'd call archiver.add(stuff-to-add) multiple times. As you see, the file (thus, the filename) is naturally bound to the XMLArchiver instance, not to the method adding files to it.
Currently we are writing our bachelor thesis about the implementation of a Compiler for an academic object-oriented mini programming language.
We want to be precise in our documentation, and we're currently discussing if a constructor is a routine.
What we think points out that a constructor is a routine is that it has a block of Commands, Parameters and local variables. Despite the missing name, all other attributes of other routines are given.
What we think points out that a constructor is not a routine is that it can only be called once per instance.
We are not sure if this question has a clear answer, or if the definition is different from theory to theory.
We would be happy if someone could give a pointer to some literature about this semantic question.
Best
Edit: Some Information about how we name specific things in our Language:
We have functions and procedures. Functions do have a return value, procedures don't.
A constructor is like an unnamed procedure (without explicit return value)
a constructor is called implicit, java like: x := new X(1, new Y())
Parameters are defined during the definition of a constructor. The own instance (this) is not considered a parameter but provided implicitly
Thanks for your answers so far, they're helping with the though process.
This depends on language - and for this academic language - I would not say that a constructor is a routine. I say that because in not saying that it is a routine, a separation is kept: unless the language explicitly unifies routines/functions/constructors, don't say it does :)
Now, consider these counter-examples (and there are many more, I am sure):
Languages like Eiffel allow giving constructors different names (which I think is awesome and wish was used more).
Languages like Ruby don't have a "new" operator and invoking a constructor appears as invoking any (class) method. Ruby doesn't even have a way of signaling that a method acts as a constructor (or factory method, as it were).
Constructors in languages like JavaScript are just functions which can be run in a special context when used with new.
Also, at some level it may be viewed that there needs to be no difference in calling a constructor multiple times (you get back a new object - so what?) than calling a function multiple times (where one might get back the same value). Consider that the new object may be immutable and may have value equality with other objects.
That is, considering the following code, is there a constructor used?
5 4 vec2 "1" int 2 vec2 add puts
I made it up, but I hope it makes a point. There may or may not be a constructor or an external difference between a constructor and an ordinary function depending upon how the specific language views the role (or even need) of constructors.
Now, write the language specification as deemed fit and try to avoid leaking implementation details.
Constructor is a constructor.
It may be like a function(that returns value: the new object), procedure(routine, function with no return value, called on uninitialized object), it may be callable once or many times on an object (although it is arguable whever the object is of the same identity afterwards..), it may have a name or not or the name may be enforced to match the class, etc. The constructor may even "not exist" or be implicitly created by the compiler from various scattered initializers and code blocks, which otherwise would be expressions/routines/whatchamacallit.
It all depends on your language that you compile and on what do you mean by 'function', 'routine', or even 'parameters' (i.e. is 'this' a parameter?).
If you want to ask about such thing, first describe/define your language and all your terms that you want to use (what is a class? method? function? routine? parameter? constructor? ...) and then, well, most probably you will automatically deduce the answer matching your ontology.
A constructor is a function with special semantics (such that it is called in specific context - as part of object construction), but it is a function anyway - it can have parameters, it has usual flow of control, it can have local variables, etc. It is not better or worse than any other function. I'd say it is a routine.
From outside, a constructor can be seen as a class method, with an instance of that class as return value. Insofar, the claim that "it can only be used once per instance" does not hold water, since there is no instance yet when the constructor is used.
From inside, some special keywordish name like "this" is bound to the uninitialized instance.
Usually, there is some syntactic sugar, like a new keyword. Also, the compiler may help to make sure the instance is properly initialized.
It is special insofar as the functionality of creating a new object is nowhere else provided. But as far as its usage is concerned, a constructor is not (or at least should not be) different from any other class method that happens to return an instance of the class.
BTW, is "routine" an established term in OOP?
I think that a Routine is what is that can be called explicitly as and when required by the caller on a constructed object/class, while a constructor can be called a special type of routine that is called at runtime when the instance of the class is requested.
A constructor helps only in constructing and initializing the class
object and its variables.
It may or may not accept parameters, it can be overloaded with
different set of parameters
If the constructor has no parameters and also no code inside its code
block, you may want to omit it
Some languages automatically create a default parameter-less
constructor (like C#) if you do not provide your own constructor
A constructor can have an access modifier to restrict the creation
scope of the class
A constructor cannot have a return type because its constructing the
same class in which it is declared, and obviously there is no point
returning the same type (may be that's the reason some languages use same name for the constructor as the class name)
All the implementation rules for a constructor differ from language to language
Furthermore, the most important requirement of a well written constructor is that after it is executed it should leave the class object in a valid state
A constructor (as in the name) is only executed by the compiler when you create a new instance of that class.
The general idea is this: You put some set of operations which should be executed during the startup and that is what is done on the constructor. So this implies, you cannot call a constructor just like the other methods of your class.
I often need to decide between these two strategies for the object design:
An object that is fully initialised and ready to use after its construction. The constructor often requires a complex list of parameters, hence the object initialisation is nontrivial. All objects having it as a member variable will also need nontrivial constructors. This may lead to code whose complexity is concentrated at object constructors, often making the code hard to follow.
An object with default constructor. The object variables are set individually by means of setter methods. This approach has the disadvantage that most methods need to check whether the object is fully initialized, hence complicating the code.
What is your personal preference between the two, and how do you decide when to use one or the other?
In my opinion if a constructor is getting too bloated it's time to split up your object in more different, smaller objects. This might be impossible in some rare cases, but in most cases it can be done.
Neither.
Huge parameter lists indicates the object does too much. Lots of properties that need to be set before the object can have a valid and useful output indicates it does too much.
So neither approach is a solution as far as I'm concerned.
There are lots of ways to break these things up, but outside of a specific scenario, the only rule is, "It needs doing".
Aggregation into other objects, "controller" classes, various communicator patterns. Are some categories first class objects, can some be hidden in the implementation.
I don't accept that the two options you present are the only ones, except possibly from a pragmatic point of view in terms of getting the code out of the door. Which one I was then forced to choose, would simply depend on how many calls to the constructor with different parameters the code required, versus how much validation would be needed to confirm all the properties were set, and possibly the impact on unit tests, which because the object is a mess would be unwieldy or limited.
If a constructor takes many arguments — you call this non-trivial object initialisation — and you don't want to split up your class into smaller ones, then one alternative is to put the parameters into a Parameter Object and then only pass that object to the constructor.
Second, I believe that you should distinguish between...
object properties that absolutely must be set if the object is supposed to do its work, and there is no sensible default value. These properties should be initialised via a constructor parameter.
object properties that can be set optionally, or overridden, by the user. While you might initialise such properties in the constructor, you don't have to have a separate constructor parameter for them. Instead, you might assign a sensible default value to them that still can be overridden by the user through a setter method.
There is also an alternative to the first type of properties (those that must absolutely have a user-provided value): properties which are provided through overriding an abstract getter in a derived class:
abstract class ComplicatedFoo {
protected abstract T getSomeDependency(); // replaces required ctor parameter
}
P.S.: The book "Dependency Injection" by Dhanji R. Prasanna (Manning Publications) gives a good overview of the various ways how to initialise an object.
It's always good to initialize all your variables in the constructor, but to a default value. If it is difficult to get the value of the variable (for example, you have to call some function somewhere to get that value), you may set that value to an invalid one and then later you set the correct value.
It is not a good idea to make the constructor so complex, because you can't return an error in the constructor (I don't know if it is ok to throw an exception in the constructor or not, because I particulary don't like trhowing exceptions anywhere). Also, you can't call virtual functions there, and so on.
An approach I like when the construction of the class is complex is to create an "init" function. Then I can do something like:
Person::Person()
{
age = -1;
...
}
int Person::Init()
{
age = functionThatReturnsTheAgeFromSomeDB();
if (age == -1 )
{
return DB_ERROR;
}
...
}
And so on.
I've recently been working with someone else's code and I realized that this individual has a very different philosophy regarding private variables and method parameters than I do. I generally feel that private variables should only be used in a case when:
The variable needs to be stored for recall later.
The data stored in the variable is used globally in the class.
When the variable needs to be globally manipulated (something decidedly different from the need to read the variable by every class method).
When it will make programming substantially easier. (Admittedly vague, but one has to be in many circumstances to avoid painting oneself into a corner).
(I admit, that many of the above are slightly repetitive, but they each seem different enough to merit such treatment... )
It just seems that this is the most efficient means of preventing changing a variable by accident. It also seems like following these standards will allow for the eventual manipulation of external references (if the class is eventually modified), thus leaving you with further options in the future. Is this simply a style issue (like one true bracket or Hungarian naming conventions), or do I have justification in this belief? Is there actually a best practice in this case?
edit
I think this needs to be corrected. I used "globally" above where I actually meant, "globally by instance methods" not "globally accessible by anything, anywhere".
edit2
An example was asked for:
class foo
{
private $_my_private_variable;
public function __constructor__()
{
}
public function useFoo( $variable )
{
// This is the line I am wondering about,
// there does not seem to be a need for storing it.
$this->_my_private_variable = $variable;
$this->_doSometing();
}
private function _doSomething()
{
/*
do something with $this->_my_private_variable.
*/
// This is the only place _my_private_variable is used.
echo $this->_my_private_variable;
}
}
This is the way I would have done it:
class foo
{
public function __constructor__()
{
}
public function useFoo( $variable )
{
$this->_doSometing( $variable );
}
private function _doSomething( $passed_variable )
{
/*
do something with the parameter.
*/
echo $passed_variable;
}
}
In general, class members should represent state of the class object.
They are not temporary locations for method parameters (that's what method parameters are for).
I claim that it isn't a style issue but rather a readability/maintainability issue. One variable should have one use, and one use only. “Recycling” variables for different purposes just because they happen to require the same type doesn't make any sense.
From your description it sounds as if the other person's code you worked on does exactly this, since all other uses are basically covered by your list. Put simply, it uses private member variables to act as temporaries depending on situation. Am I right to assume this? If so, the code is horrible.
The smaller the lexical scope and lifetime of any given variable, the less possiblity of erroneous use and the better for resource disposal.
Having a member variable implies that it will be holding state that needs to be held between method calls. If the value doesn't need to live between calls it has no reason to exist outside of the scope of a single call, and thus (if it exists at all) should be a variable within the method itself.
Style is always a hard one, once you develop one you can get stuck in a bit of a rut and it can be difficult to see why what you do may not be the best way.
You should only create variables when and where they are needed, and dispose of them when you are done. If the class doesn't need a class level variable to function, then it just doesn't need one. Creating variables where you don't need them is very bad practice.
Class members should be any of the following:
A dependency of a class
A variable that represents the state of the class
A method of the class
I think the answer is straightforward if you are familiar with C++ destructors. All member variables should be assigned a way to be destructed while function parameters are not. So that's why member variables are usually the states or dependicies of an object having some kind of relation regarding their lifecycle.
I'm not sure there is a stated best-practice for using globally scoped variables versus always passing as method parameters. (By "private variables", I'm assuming you mean globally scoped variables.)
Using a globally scoped variable is the only way to implement properties in .NET (even automatic properties ultimately use a globally scoped variable, just not one you have to declare yourself).
There is a line of arguement for always using method parameters because it makes it completely clear where the value is coming from. I don't think it really helps prevent the method from making changes to the underlying value and it can, in my opinion, make things more difficult to read at times.
I would disagree with implementing it for global access or to make programming easier. By exposing these globally without filtering of any kind make it more difficult to determine access in the future.
Since object properties are meant to hold state, as stated by the others, my policy is to have all of them private by default unless I have a good reason to expose them.
It's much easier to make them public later on, if you have to, simply by writing a getter method for example (which i also don't have to think about right at the beginning of writing a class). But reeling in a public property later on may require a huge amount of code to be re-written.
I like to keep it flexible while not having to think about this more than needed.
How do you decide between passing arguments to a method versus simply declaring them as object instance variables that are visible to all of the object's methods?
I prefer keeping instance variables in a list at the end of the Class, but this list gets longer as my program grows. I figure if a variable is passed often enough it should just be visible to all methods that need it, but then I wonder, "if everything is public there will be no need for passing anything at all!"
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.
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.
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.
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
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.