What problems might arise if I didn't make a method static when I could?

Question

I have a stateless method that takes an input, and based on that input returns an output. This method has no state so in theory it could be made static. But let's say I don't do this. What problems might arise from this?

Answer 1

Is it conceptually static? Would the caller assume that the method relates to an instance and not to a class as a whole? Would the caller usually have an instance of the class available at the time of the call?

Let's say I have a class for user interface buttons. And these buttons can have a title, a color, and a font for that title. But for some reasons, the font is dictated by the operating system and therefore independent of the button. That's no reason to make the method returning the font of a button static, even if it doesn't access any state of that button.

So base your decision on what the caller expects, not on purely implementation details.

The problems that might rise if you make the method static: 1. At some point it changes and requires state, so it cannot be static anymore and you have to change code all over the place. 2. You create a subclass of your original class, and the method should behave differently for the subclass. This is trivially done by creating a virtual instance method; with your static method you have a problem.

Answer 2

The only drawback of not making a method static if it can be static is that you have to instantiate the class before calling the method.

If doing on the fly in a loop (<=> new MyClass().method() in a for), this can hurt performances and use memory for nothing.

Edit : see @gnasher729 answer for design drawback. I answered considering that the design part was already fine.

Answer 3

When you have an instance (i.e. the method is non-static), we can refer to that instance. Because we can refer to the instance, we can use a different instance in a different place: we can pass the instance as a parameter, we can use dependency injection, we link different instances to different object graphs at the same or different times. So even when the method is functional (i.e. doesn't hold state between calls), you can get object-oriented value from instances.

If you make the method static, you pretty much forgo referencing (of an instance), because there is no instance to reference.

However, enter function pointers or Lambda's (aka closures; C# has them), and you can substitute either of those for an object. So with that, we regain the ability to reference and pass as parameter, a function pointer, a delegate, or a lambda/closure. Of course, for instance delegates, there is already an instance (directly) involved, and for lambdas (that are closures) the compiler will create a class and an instance under the covers (optimization notwithstanding). So for the most part, in C# instance delegates and lambdas involve instances of classes. (Delegates from static methods don't require an instance, though AFAIK.)