When to use static methods

14. November 2008

I started using Resharper again after some time. And one thing that bugs me is that it always warns me that functions can be made static. I've kinda stopped using static methods. Static methods arent injectable, static methods make code using them less modular and less testable and static methods are the devils own handywork if you want to believe some people. On the other hand they make your code simpler by not requiring an object instance to be called. This got me thinking. Do I want to use statics or just ban them completely? And if not when is it oke to use them?

The last few years I've started using the IoC pattern extensively in my code with Windsor and Ninject to support this habit. I've found this makes my code more testable and because it forces me to think about introducing dependencies it nicely decouples everything it touches. Less problems with calling uninitialised classes etc. I think IoC is a big enabler of TDD. I used unit tests before I did IoC but usually it took me more time to write and maintain my tests than the time it saved me. Mostly because of dependencies in my code.

Calling static methods means tightly coupling your code to this method so when is it ok to do this? I've come up with the following rule of thumb. I thought I'd throw this out there to get some feedback.

Static functions should have no side effects, they should not change the objects you give them as parameters and should only generate a return value.

This also means no reading/writing of files, databases etc. No network access. No PInvokes (yeah i know they are static by definition, that's why I wrap them in facade classes).

The reasoning behind this is that you should have no reason to want to replace a call to a static method in your code. Not for testing and not in production because you can't. If you want to unit-test or use code that uses this method you're forced to see it as a whole with the static method call itself.

What am I left with? Mostly simple utility methods. Parsing path names for example. Simple calculations. Simple factory methods, although those are an edge case to me. 

What do you think? 

Comments

11/14/2008 4:27:12 PM

trackback

Trackback from DotNetKicks.com

When to use static methods

DotNetKicks.com

11/16/2008 6:39:51 PM

Khalid Abuhakmeh

Well I agree with you that static methods can be a problem if you have them sitting publicly on your classes. That is why I try to make static classes that have static methods. For example, I build a static class used mainly for serialization.

You also have to look at what your concerns are and what your class is trying to achieve. In the case of serialization, if it is just a mechanism to save the data and is never exposed outside of the class, then I feel that is an ok compromise. If the data is passed outside, then it becomes something you might want to abstract.

In the end, I think extension methods will help ease this problem.

Khalid Abuhakmeh United States

11/17/2008 9:58:14 AM

Mendelt

Hi Khalid,

Good that you mention extension methods. Although at their core extension methods are just static methods and don't add much, they kind of force you to use them "the right way".

Mendelt

1/13/2009 3:46:45 AM

busby seo test

thanks for sharing your ideas i really appreciate it!great post!

busby seo test United States

Comments are closed

Powered by BlogEngine.NET 1.5.0.7
Theme adapted from BlogEngine.NET standard theme by Mads Kristensen

Mendelt Siebenga

Mendelt Siebenga with coffeeMendelt Siebenga works as a C# programmer. In his spare time he's been known to pick up Python, Lisp and even a soldering iron from time to time.

You can also find me here