2

There are various refactoring options in Visual Studio to use at the time of coding. When we extract and create a new method. Then Visual Studio decide whether the new method will be static or instence depending on the usage inside the new method. If that method use some intence member of the class then it creates as instence method, if it does not use any instence member of the class then it creates the method as static. I can understand that if there is no instence member usage then it is better to declare that method as static to prevent initialization for every object. Static method initilize only once at the time of class load.

Extract method in Visual Studio

But the question is if there are many static methods inside various classes of a application, then performance will hurt? Because many object of that class will share same static method of that class? Should we do thread safety management to that static method? Or in this kind of setuation it is better to simplily create instence method if there are no usage of instence member of the class?

  • There is very little difference between static methods and instance methods. The main distinction is that instance methods have an implicit parameter for this. – CodesInChaos Jan 23 '14 at 12:19
  • Technically, that menu is a Resharper feature, not a visual studio feature. Just FYI for anyone trying to find it in a vanilla install. – Bobson Jan 23 '14 at 15:32
  • @Bobson: without Resharper, the menu might look different, but the feature (and the keyboard shortcut) is still the same, including its behaviour concerning static methods. – Doc Brown Jan 23 '14 at 16:07
  • @DocBrown - You're right. I've never noticed that before. Interestingly, the Resharper version does let you specify whether to make the new method static or not, but the VS default (as described in the question) decides on its own. – Bobson Jan 23 '14 at 17:58
6

It's not so much a performance issue but a thread safety issue. If you have static methods that mutate static data then yes, these will need to lock access to that data (though granted this could cause performance issues), this of course is also true of non static methods.

However it is much more common for static methods to be pure functions in the first place, in this case no locks may be required.

  • 4
    -1, non-static member functions mutating static data are exactly as unsafe as static member functions. You make the same error as the OP - intermixing the implications of static member variables vs. static member functions. – Doc Brown Jan 23 '14 at 12:40
  • 2
    @DocBrown Agreed, but of course mutable static data is a code smell in its own right :-) – Ross Patterson Jan 23 '14 at 12:42
  • @RossPatterson: but that was not the question of the OP. – Doc Brown Jan 23 '14 at 12:43
  • 1
    @DocBrown: I think that, essentially, it is. If you have a great many pure functions then there is no downside to making them static--indeed, it better shows intent and is perhaps superior. However, if they are impure, then it is very very bad to make them static. The entire question hinges on that sub-question. – Phoshi Jan 23 '14 at 12:46
  • 1
    @jk.: my point is that the OP has a misunderstanding about static methods - and your original answer did not clarify that. – Doc Brown Jan 23 '14 at 12:59
4

But the question is if there are many static methods inside various classes of a application, then performance will hurt?

Absolutely not, quite the opposite, since static methods don't have a "this" parameter, so calling a static method will be a little bit faster than calling a non-static method, since there is one parameter less to be pushed on the stack. In most real world cases, however, the speed difference is negligible.

Because many object of that class will share same static method of that class?

For objects, "sharing a method" is like "sharing immutable data" - a thread-safe form of "sharing".

Should we do thread safety management to that static method?

You should add thread safety management to any method mutating data which might be shared between threads (like static data). A method being static does in no way imply the need for putting any locks in there. Its only shared data which can cause threading problems, and it does not matter if the method accessing that data is itself static or not.

So the VS refactoring "Extract method" does in no way introduce any performance- or thread safety issues into your code. At least, none which had not been in the code before the refactoring.

  • "You should add thread safety management to any method mutating shared data" - static or just exposed, doesn't really make much difference – Caleth Dec 18 '17 at 14:45
  • @Caleth: sure, edited my answer accordingly. – Doc Brown Dec 18 '17 at 15:04
2

I always refactor to static methods if possible just because of what it communicates:

  1. It does not mutate state on an instance of the class.
  2. Therefor it can easily be moved to another class (Move refactoring).
  3. Getting a large number of static methods can be a sign some other class is trying to get out.

Static method invocation is faster then instance method invocation, although the difference tends to be is insignificant (see this question).

When also using static state in the static method you need to be careful with re-entrancy. It's more common to change the static method to an instance method, so it can use members on the instance, then it is to introduce static state.

When in doubt leave the static out.

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.