none
Question about the use of static objects RRS feed

  • Question

  • I'm a bit inexperienced in C# and I've not made much use of the static keyword in any case.

    My question is this:

    Given a static public class in a 4.0 Web application (VS2012) and given a static public property in that class, if a call to a static method within that class sets that property and the calling class immediately retrieves the value of the static public property, is that in general a good programming practice?  Are there any risks? 

    (I've already tried this and I know it works.  At least it looks like it.)

    Thursday, October 18, 2012 5:03 PM

Answers

  • When to use a static class?

    static class CompanyInfo
    {
        public static string GetCompanyName() { return "CompanyName"; }
        public static string GetCompanyAddress() { return "CompanyAddress"; }
        //...
    }

    - Use a static class as a unit of organization for methods not associated with particular objects. Also, a static class can make your implementation simpler and faster because you do not have to create an object in order to call its methods. It is useful to organize the methods inside the class in a meaningful way, such as the methods of the Math class in the System namespace.

    Check more info from here Static Classes and Static Class Members (C# Programming Guide)


    If you get your question answered, please come back and Alternate TextMark As Answer.
    Web Developer

    Thursday, October 18, 2012 5:10 PM
  • Hi,

    in general try to avoid static keyword, because what is marked as static, it remain in the memory as long as this application is alive (this is the only risk you take, else there is no problem with using of static keyword).

    If you create a static class, this class can only contains static members (fields, properties, methods...), so it better to create non-static class, and if needed static memeber inside of it.

    Static classes are mostly meant for so class factories. The benefit of static classe (and their members) is that you dont need to create an instasnce of that class.


    Mitja

    Thursday, October 18, 2012 5:12 PM
  • As soon an the method (or anybody else) sets a value for the static property, it is immediately avaliable to the class. So, why do you think it's a risk. There is no problem at all.

    Please mark this post as answer if it solved your problem. Happy Programming!

    Thursday, October 18, 2012 5:12 PM
  • I'm a bit inexperienced in C# and I've not made much use of the static keyword in any case.

    My question is this:

    Given a static public class in a 4.0 Web application (VS2012) and given a static public property in that class, if a call to a static method within that class sets that property and the calling class immediately retrieves the value of the static public property, is that in general a good programming practice?  Are there any risks? 

    (I've already tried this and I know it works.  At least it looks like it.)

    Well, what would be the point of doing that?  What is there to gain?  As for risks, it's possible for another thread to have modified the value after you set it and before you read it.  If you want that to be an option then the only benefit to reading the value you just wrote would be to see if it changed; if that didn't happen you may as well just use whatever you used to set it in the first place.

    In general you should default to using non-static fields.  Use static fields if you have a compelling reason to, and you know it falls into the set of circumstances in which it conceptually makes sense.  Without knowing what you're conceptually trying to do, we can't know if a static field is appropriate.

    Thursday, October 18, 2012 5:28 PM

All replies

  • When to use a static class?

    static class CompanyInfo
    {
        public static string GetCompanyName() { return "CompanyName"; }
        public static string GetCompanyAddress() { return "CompanyAddress"; }
        //...
    }

    - Use a static class as a unit of organization for methods not associated with particular objects. Also, a static class can make your implementation simpler and faster because you do not have to create an object in order to call its methods. It is useful to organize the methods inside the class in a meaningful way, such as the methods of the Math class in the System namespace.

    Check more info from here Static Classes and Static Class Members (C# Programming Guide)


    If you get your question answered, please come back and Alternate TextMark As Answer.
    Web Developer

    Thursday, October 18, 2012 5:10 PM
  • As soon an the method (or anybody else) sets a value for the static property, it is immediately avaliable to the class. So, why do you think it's a risk. There is no problem at all.

    Please mark this post as answer if it solved your problem. Happy Programming!

    Thursday, October 18, 2012 5:12 PM
  • Hi,

    in general try to avoid static keyword, because what is marked as static, it remain in the memory as long as this application is alive (this is the only risk you take, else there is no problem with using of static keyword).

    If you create a static class, this class can only contains static members (fields, properties, methods...), so it better to create non-static class, and if needed static memeber inside of it.

    Static classes are mostly meant for so class factories. The benefit of static classe (and their members) is that you dont need to create an instasnce of that class.


    Mitja

    Thursday, October 18, 2012 5:12 PM
  • I'm a bit inexperienced in C# and I've not made much use of the static keyword in any case.

    My question is this:

    Given a static public class in a 4.0 Web application (VS2012) and given a static public property in that class, if a call to a static method within that class sets that property and the calling class immediately retrieves the value of the static public property, is that in general a good programming practice?  Are there any risks? 

    (I've already tried this and I know it works.  At least it looks like it.)

    Well, what would be the point of doing that?  What is there to gain?  As for risks, it's possible for another thread to have modified the value after you set it and before you read it.  If you want that to be an option then the only benefit to reading the value you just wrote would be to see if it changed; if that didn't happen you may as well just use whatever you used to set it in the first place.

    In general you should default to using non-static fields.  Use static fields if you have a compelling reason to, and you know it falls into the set of circumstances in which it conceptually makes sense.  Without knowing what you're conceptually trying to do, we can't know if a static field is appropriate.

    Thursday, October 18, 2012 5:28 PM
  • You can also make use of the static constructor to se values for static properties or fields:

        static class Program
        {
            static string MyProperty { get; set; }

            static Program()
            {
                MyProperty = "Hi!";
            }
    Anyway if it is a web app, remember the static stuff is executed on class loading and if your webb app is recycled by the hoster (IIS ?) you lost static stuff (you lost the process in fact) and then you load it again on any http:// call to it, this could be no problem or a big one, since the process life cycle is handled by IIS.

    -


    Thursday, October 18, 2012 6:55 PM
  • Use static, if it is required: eg: helper and utility methods can be wrap up in a static class. This will be bit faster to execute because no need to create an instance.
    Thursday, October 18, 2012 10:04 PM
  • As soon an the method (or anybody else) sets a value for the static property, it is immediately avaliable to the class. So, why do you think it's a risk. There is no problem at all.



    static properties are not inherently thread-safe.

    jon.stromer.galley


    • Edited by jgalley Thursday, October 18, 2012 11:40 PM
    Thursday, October 18, 2012 11:38 PM
  • Use static, if it is required: eg: helper and utility methods can be wrap up in a static class. This will be bit faster to execute because no need to create an instance.
    This shouldn't factor into the decision at all.  Either the data logically should be global state, in which case it should be static, or it's not, in which case it shouldn't be.  They do entirely different things, so performance never really comes into play at all.  If they actually did the same thing, functionally, then you could validly compare the performance differences.
    Friday, October 19, 2012 2:02 PM
  • Like I said, I'm a bit inexperienced in C#.

    (I'm probably going to do something else.)

    • Edited by B. Chernick Wednesday, October 24, 2012 6:30 PM
    Wednesday, October 24, 2012 6:28 PM