none
When should I prefer static routines, and when should I avoid them? RRS feed

  • Question

  • Hi All,

     

    That’s what I’m thinking about.

    Of course I’ve got some answer but I want to know yours.

    Thanks

    Saturday, March 22, 2008 8:36 AM

Answers

  • If the method uses member variables (that is, fields declared at the class-level), then it must not be static.  A compile-time error will occur if you try to declare it static in this case.

     

    On the other hand, if it does not use member variables, you can declare it static.  This may result in a small performance improvement.

     

    The larger question is often whether or not you should have a "public static" method.  These static methods are interesting because you can call them esentially from anywhere without having an object reference (think like the Math.Round() function).  This is often a judgment call.  Keep in mind that if you ever need to remove the static modifier in the future, that will be a breaking change to your class that will cause you to have to modify all of the code that calls the method.

     

     

    Saturday, March 22, 2008 2:05 PM
  •  Michael Bird from Sharp Dudes wrote:

    Static methods are generally thread-safe



    Lie! ... or half true. You can/could for example work with the instance of a singleton within a static method. A static method is thread safe as long you are not working with a "self reference" to an instance or any "global" object which is not thread safe. Whether to use static methods or not can be a performance issue (why not use assembler?) but should be a design issue in most cases. For example if you don't want direct instantiation of a class (for what reason ever) via constructor you may define only a private constructor and a static method to return a new instance.
    Assume you also want to keep track of the instances and do some handling on construction and disposing doing funny stuff with collections etc. This is everything but thread safe as long as you do not take care about it.

    So i would say "static" is more a design thingy.
    Thursday, March 27, 2008 3:56 PM

All replies

  • If the method uses member variables (that is, fields declared at the class-level), then it must not be static.  A compile-time error will occur if you try to declare it static in this case.

     

    On the other hand, if it does not use member variables, you can declare it static.  This may result in a small performance improvement.

     

    The larger question is often whether or not you should have a "public static" method.  These static methods are interesting because you can call them esentially from anywhere without having an object reference (think like the Math.Round() function).  This is often a judgment call.  Keep in mind that if you ever need to remove the static modifier in the future, that will be a breaking change to your class that will cause you to have to modify all of the code that calls the method.

     

     

    Saturday, March 22, 2008 2:05 PM
  • Hi BinaryCoder

    What about the thread safety?


    Regards
    Thursday, March 27, 2008 10:57 AM
  • Static methods are generally thread-safe by default since you are not accessing any of the  instance data in your object.

    Thursday, March 27, 2008 2:53 PM
  •  Michael Bird from Sharp Dudes wrote:

    Static methods are generally thread-safe



    Lie! ... or half true. You can/could for example work with the instance of a singleton within a static method. A static method is thread safe as long you are not working with a "self reference" to an instance or any "global" object which is not thread safe. Whether to use static methods or not can be a performance issue (why not use assembler?) but should be a design issue in most cases. For example if you don't want direct instantiation of a class (for what reason ever) via constructor you may define only a private constructor and a static method to return a new instance.
    Assume you also want to keep track of the instances and do some handling on construction and disposing doing funny stuff with collections etc. This is everything but thread safe as long as you do not take care about it.

    So i would say "static" is more a design thingy.
    Thursday, March 27, 2008 3:56 PM
  • Your theory does not match my reality. Static methods are not thread safe. That I know from many years of experience programming multi-threaded websites.

     

    Wednesday, April 2, 2008 1:06 PM
  • What kind of global objects are you talking about? I had modules in VB 8 with function, which created corrupt data once in a while. When I replaced those modules with classes, then a set of data corruption issues disappeared from my website.

     

    Wednesday, April 2, 2008 1:11 PM