This question is inspired by Mike Nakis' answer to a question I asked earlier: Should a Calculator be a value type or an entity type?. Please see the code below:

public class Calculator
    private readonly int Number1;
    private readonly int Number2;
    private readonly int Answer;

    public Calculator(int _Number1, int _Number2)
        Number1 = _Number1;
        Number2 = _Number2;
        Answer = Add();

    private int Add()
        return Number1 + Number2; //plus 30 lines of code

Notice that there are two instance variables called: Number 1 and Number 2. This would also work (where both numbers are local variables):

public class Calculator
    public int Add(int Number1,int Number2)
        return Number1 + Number2; //plus 30 lines of code

I understand the difference between instance variables and local variables i.e. stack and heap; scope etc.

When designing a system (UML) ; how do you decide whether to use a local variable or an instance variables. The factors I can think of are as follows:

1) Easier to make a call immutable

The reason I ask is because I read a lot of questions on here where I think an instance variable should be used; however a local variable is used. Is there a rule that I am not aware of similar to: "Use aggregation over inheritance".

I am talking strictly from a DDD and best practices point of view. I realise this does not always apply in the real world because of time constraints etc.


In your first example, clients of Calculator would have to construct a new Calculator every time they want to add numbers. This isn't very efficient! It will involve a lot of allocations from the heap and will require more garbage collection.

Your second solution is much simpler--the same instance can be used for the entire program. You only need one instance of Calculator for the entire system!

Here are a few guidelines I use:

  1. Generally variables should have the smallest scope possible. The reason for this is because it's easier to reason about. Local scope is small, and by looking at a single method you can see the entire scope of the variable. An instance variable can be accessed by all the methods of the class, so there is more to reason about for instance variables.

  2. Immutability is a quality that leads to fewer bugs and better maintainability. You've used immutable instance variables, but they don't have to be immutable. Mutable instance variables make the class state-ful and makes things like thread-safety and testing more of a challenge. Local variables don't affect the statelessness of the class, so they're better.

  3. Think of your class as though it had an interface in front of it. Think about how your class would be abstracted if necessary. This can help you decide what should be a constructor-injected dependency (i.e. immutable instance value) and what should be a function parameter (i.e. local value)

  • Thanks. However, could you have a look at my other question here: stackoverflow.com/questions/44615081/…. Using local variables appears to make it impossible to use an AutoMocker. Do you agree? – w0051977 Jun 18 '17 at 15:38
  • @w0051977: If you feel the need to create an overall worse design just to support mocking, then you are probably overusing mocking. Why would you even mock a method which adds two numbers? – JacquesB Jun 28 '17 at 8:36

Turning local variables into instance variables (for no particular reason) violates the least visibility scope principle. It causes problems when refactoing especially when a method should be moved to another class.

Also Instance variables introduce state to the object.

We try to avoid state in our objects because it makes reuse harder and may cause problems when it comes to concurrency.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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