When not to use static classes

There has been instances in every application where we are tempted to write static methods as they are much easier to call but that comes with a catch. lets look at some use cases when we should and should not use static classes/methods

If we are sure about a class that would not change, For example a simple utility that reads application configuration from app config or a calculation utility that performs some operations on the input parameters and returns an output, we should think of using static methods.

I have taken below points from stackoverflow answer stackoverflow.com/questions/241339/when-to-.. and this topic describes the reason behind avoiding static methods/classes

  1. A static method cannot behave differently based on the type of class that is calling. It is a simple polymorphism. For example, in below code, if we had used static class, we could not avail polymorphism and implement an override based on the need. Even though our class may work with Car at the moment, there is greater chance that we may extend this functionality and by using static methods we are making this code very difficult to change.
public class Assembler
    {
        private readonly IVehicle vehicle;

        public Assembler(IVehicle vehicle)
        {
            this.vehicle = vehicle;
        }

        public void Assemble()
        {
            vehicle.GetEngine();
        }

    }
  1. Unit testing An obvious problem is unit testing. We cannot inject any mock interfaces if we use static methods or classes. So a general rule of thumb would be, write tests after consuming a static method. If you can test it easily, it is a good design decision.

There are more reasons why and when we should avoid static methods, you can find them here

sites.google.com/site/steveyegge2/singleton..