It’s really hard to give good advice on such a broad topic. The honest answer is: it depends on what you want to accomplish.

1) Member variables could represent state of an object. This might or might not be, what you intended to do. If your object lives in a web- / concurrency-context, then that is most of the time not, what you want. In these contexts, most of the time you want statelessness / immutability. If an object is shared and reads and writes are permitted, there is trouble. Of course there are ways to avoid such problems (e.g. locks etc.) but it is not a good idea to have mutable objects.

2) Another usecase for member variables is to hold dependencies for the object: e.g. dependencies to repositories, services, etc. These are most of the time injected once; sometimes via constructor-injection or via setter-injection. It would make no sense to avoid using membervariables for these dependencies; on the other hand you would have to inject needed dependencies with each function call. This pollutes the method signature unnecessary and makes using your api complicated.

3) And there is the space in between. If an object is not shared and the membervariable does not represent a dependency you are free to do, what you like. It is wrong to think of them as global variables since they are not global – they are limited to the object. And one pillar of object oriented design is encapsulation or information hiding. It’s like dancing naked in your living room: as long as nobody sees it – who cares?

A member variable is any variable that is scoped to the class. That means that any code within the class can access the variable. How the variable is used or how it is accessed doesn’t matter, with respect to it’s member status. Member variables and class/object state are the same thing.

Example:

public class MyClass
{
   // Not a member variable; never changes.
   private const pi = 3.14159;

   // class state; member variable, but shared with all object instances. 
   private static object locker;

   // member variable.
   private List<double> list;

   // member variable.
   private int counter;

   // member variable, but properties are preferred.
   public bool IsSingleton; 

   // not a member variable; part of the class's external API.
   public int Counter
   {
       get { return counter; }
   }

   public double CalculateAverage
   {
       // not a member variable; scoped to method.
       double sum;

       for (int i=0; i< list.Length; i++)
       {
           sum += list[i];
       }
       return sum / list.Length;
   }   
}

One use of “declaring variables as members” is for attributes. Them being things that describe the thing you are modeling that, maybe, some external consumer would want to ask. For example the name and age of a person are examples of attributes. These atributes are usually modified using a setter method and read using a getter method.

Attributes are part of the “state” of an object. But other variables besides the attributes are part of the state also.

The second possible use is for those kinds of variables. Such variables contain information that are usually read from and written to by several of the class method.

Examples:

• an internal counter ( not the counters in for loops )
• an open database connection
• a list of processed items
• a flag indicating the object is in certain state (waiting, closed, open, available, etc.)

These variables are candidates to be member variables even when no one outside the class need to know them.

What you say about just passing everything as parameters to the methods indicates that such methods are not cohesive to the class and that they should be static.

Maybe you are not modelling real world concepts in a OO way and you are just using classes as applications, i.e, the application is the class, and that’s why you don’t find it natural to declare member variables.

One additional tip is that if you find you are constantly passing the same parameter between several methods, chances are that method should be a member.

Recomendation:

Use classes to model real life entities, like BankAccount, Player, Chessman, etc. Don’t make a giant class with a giant main method and a lot of helper functions.