OO Design, pass parameters between private methods or access member variable? [closed]

Question

Say I have the following class:

class MyClass
{
    private int memberVar;

    public MyClass(int passedInVar)
    {
        memberVar = passedInVar;       
    }
}

In the constructor you pass in an int and assign it to a private member variable.

My question is, is it better to pass that int variable around between private methods of the class, or to not pass the int variable as a parameter and instead have each private method directly access the private membervar?

i.e. Is this (Example A):

class MyClass
{
    private int memberVar;

    public MyClass(int passedInVar)
    {
        memberVar = passedInVar;       
    }

    public MyPublicMethod()
    {
        MyPrivateMethod(memberVar);
    }

    public MyPrivateMethod(int variable)
    {
        // Do something with passed in variable...
    }
}

better than this (Example B):

class MyClass
{
    private int memberVar;

    public MyClass(int passedInVar)
    {
        memberVar = passedInVar;       
    }

    public MyPublicMethod()
    {
        MyPrivateMethod();
    }

    public MyPrivateMethod()
    {
        // Do something with memberVar...
    }
}

The reason I ask is that I find myself switching between the two styles.

I find that example the style of example A shows more intent for the code. You can see what is being passed between private methods so it's more obvious what is being affected by that method.

Whereas Example B is cleaner because the memberVar isn't being passed between private methods. However the code feels more "side-effecty" because it's not always obvious which private member variables the method is acting on.

I'd appreciate your opinions on which approach you consider best.

Answer 1

The real question is not "which way is better", it is whether your member variable should really be a member of your class or not. If it is only a member variable to clean up the argument list for some operation... that is not a good reason to add members to a class. Not only does it polute your model and makes your code harder to understand, it scatters dependencies which is never a good thing. If you can make your method static by passing in its dependencies it is probably good to do so.

If the member is a rightful member of your class, you probably do not need a separate method at all. Then passing the member from one method to the next makes no sense because the member can always be accessed by any method,

Answer 2

Instead of telling you which is better, I prefer to give you some hints:

• Class fields should never be accessed directly. They should be encapsulated using properties.
• Instance methods, since they're part of some specific class instance shouldn't accept parameters unless the values required during the execution of some method requires more information than the one contained in the object itself or if the data shouldn't be held by the class because they not represent actual properties on the whole class (i.e. the data is unrelated to the class).
• You shouldn't create a private method just to operate with class fields, because you should already encapsulate them using properties.
• Class fields that are only set during construction time should be readonly to avoid human mistakes setting it during the life-time of the whole object. At least, you should set a property where its setter is private (i.e. public string Name { get; private set; }).

Expanding when to use input parameters

For example, calculating the area of a rectangle would look as follows:

public class Rectangle
{
     public int Area { get; private set; }

     public void CalcArea(int a, int b) 
     {
          Area = a * b;
     }
}

• Area is a class property. You wouldn't pass the area as argument of CalcArea, would you? ;)
• You need to supply the length of rectangle's sides.

Answer 3

Voted for the second solve. You are working with current context and it is a normal - use context parts. It's right for life, it's right for code. For example imaging that you use strategy 1. If one of your private methods, which called 2 or more once, needs change signature, then you need change code at 2 or more places. Otherwise, when you use context, it`s not needed.

Answer 4

I would chose the first approach in this concrete scenario, as the function declaration clearly manifests what its execution depends from.

In second case you have "hidden" variable that holds the state during entire lifetime of the type instance.

There are number pros and cons, and that pretty much depends on all program architecture, your design goals and personal test.

Considering all I said above, still, having clear and concise definition of the function which at the same time clearly shows its execution dependencies (like in your first choice) is a huge benefit I find hard to argue about.