When to use static classes in C

Question

Here s what MSDN has to say under When to Use Static Classes    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    To me  that example doesn t seem to cover very many possible usage scenarios for static classes  In the past I ve used static classes for stateless suites of related functions  but that s about it  So  under what circumstances should  and shouldn t  a class be declared static

User · Answer

Based on MSDN    You cannot create the instance for static classes If the class declared as static  member variable should be static for that class Sealed  Cannot be Inherited  Cannot contains Instance constructor Memory Management   Example  Math calculations  math values  does not changes  STANDARD CALCULATION FOR DEFINED VALUES

User · Answer

This is another old but very hot question since OOP kicked in. There are many reasons to use(or not) a static class, of course and most of them have been covered in the multitude of answers.

I will just add my 2 cents to this, saying that, I make a class static, when this class is something that would be unique in the system and that would really make no sense to have any instances of it in the program. However, I reserve this usage for big classes. I never declare such small classes as in the MSDN example as "static" and, certainly, not classes that are going to be members of other classes.

I also like to note that static methods and static classes are two different things to consider. The main disadvantages mentioned in the accepted answer are for static methods. static classes offer the same flexibility as normal classes(where properties and parameters are concerned), and all methods used in them should be relevant to the purpose of the existence of the class.

A good example, in my opinion, of a candidate for a static class is a "FileProcessing" class, that would contain all methods and properties relevant for the program's various objects to perform complex FileProcessing operations. It hardly has any meaning to have more than one instance of this class and being static will make it readily available to everything in your program.

User · Answer

I only use static classes for helper methods, but with the advent of C# 3.0, I'd rather use extension methods for those.

I rarely use static classes methods for the same reasons why I rarely use the singleton "design pattern".

User · Answer

When deciding whether to make a class static or non-static you need to look at what information you are trying to represent. This entails a more 'bottom-up' style of programming where you focus on the data you are representing first. Is the class you are writing a real-world object like a rock, or a chair? These things are physical and have physical attributes such as color, weight which tells you that you may want to instantiate multiple objects with different properties. I may want a black chair AND a red chair at the same time. If you ever need two configurations at the same time then you instantly know you will want to instantiate it as an object so each object can be unique and exist at the same time.

On the other end, static functions tend to lend more to actions which do not belong to a real-world object or an object that you can easily represent. Remember that C#'s predecessors are C++ and C where you can just define global functions that do not exist in a class. This lends more to 'top-down' programming. Static methods can be used for these cases where it doesn't make sense that an 'object' performs the task. By forcing you to use classes this just makes it easier to group related functionality which helps you create more maintainable code.

Most classes can be represented by either static or non-static, but when you are in doubt just go back to your OOP roots and try to think about what you are representing. Is this an object that is performing an action (a car that can speed up, slow down, turn) or something more abstract (like displaying output).

Get in touch with your inner OOP and you can never go wrong!

User · Answer

When deciding whether to make a class static or non-static you need to look at what information you are trying to represent. This entails a more 'bottom-up' style of programming where you focus on the data you are representing first. Is the class you are writing a real-world object like a rock, or a chair? These things are physical and have physical attributes such as color, weight which tells you that you may want to instantiate multiple objects with different properties. I may want a black chair AND a red chair at the same time. If you ever need two configurations at the same time then you instantly know you will want to instantiate it as an object so each object can be unique and exist at the same time.

On the other end, static functions tend to lend more to actions which do not belong to a real-world object or an object that you can easily represent. Remember that C#'s predecessors are C++ and C where you can just define global functions that do not exist in a class. This lends more to 'top-down' programming. Static methods can be used for these cases where it doesn't make sense that an 'object' performs the task. By forcing you to use classes this just makes it easier to group related functionality which helps you create more maintainable code.

Most classes can be represented by either static or non-static, but when you are in doubt just go back to your OOP roots and try to think about what you are representing. Is this an object that is performing an action (a car that can speed up, slow down, turn) or something more abstract (like displaying output).

Get in touch with your inner OOP and you can never go wrong!

User · Answer

I use static classes as a means to define "extra functionality" that an object of a given type could use under a specific context. Usually they turn out to be utility classes.

Other than that, I think that "Use a static class as a unit of organization for methods not associated with particular objects." describe quite well their intended usage.

User · Answer

I wrote my thoughts of static classes in an earlier Stack Overflow answer  Class with single method -- best approach   I used to love utility classes filled up with static methods  They made a great consolidation of helper methods that would otherwise lie around causing redundancy and maintenance hell  They re very easy to use  no instantiation  no disposal  just fire n forget  I guess this was my first unwitting attempt at creating a service-oriented architecture - lots of stateless services that just did their job and nothing else  As a system grows however  dragons be coming   Polymorphism  Say we have the method UtilityClass SomeMethod that happily buzzes along  Suddenly we need to change the functionality slightly  Most of the functionality is the same  but we have to change a couple of parts nonetheless  Had it not been a static method  we could make a derivate class and change the method contents as needed  As it s a static method  we can t  Sure  if we just need to add functionality either before or after the old method  we can create a new class and call the old one inside of it - but that s just gross   Interface woes  Static methods cannot be defined through interfaces for logic reasons  And since we can t override static methods  static classes are useless when we need to pass them around by their interface  This renders us unable to use static classes as part of a strategy pattern  We might patch some issues up by passing delegates instead of interfaces   Testing  This basically goes hand in hand with the interface woes mentioned above  As our ability of interchanging implementations is very limited  we ll also have trouble replacing production code with test code  Again  we can wrap them up  but it ll require us to change large parts of our code just to be able to accept wrappers instead of the actual objects   Fosters blobs  As static methods are usually used as utility methods and utility methods usually will have different purposes  we ll quickly end up with a large class filled up with non-coherent functionality - ideally  each class should have a single purpose within the system  I d much rather have a five times the classes as long as their purposes are well defined   Parameter creep  To begin with  that little cute and innocent static method might take a single parameter  As functionality grows  a couple of new parameters are added  Soon further parameters are added that are optional  so we create overloads of the method  or just add default values  in languages that support them   Before long  we have a method that takes 10 parameters  Only the first three are really required  parameters 4-7 are optional  But if parameter 6 is specified  7-9 are required to be filled in as well    Had we created a class with the single purpose of doing what this static method did  we could solve this by taking in the required parameters in the constructor  and allowing the user to set optional values through properties  or methods to set multiple interdependent values at the same time  Also  if a method has grown to this amount of complexity  it most likely needs to be in its own class anyway   Demanding consumers to create an instance of classes for no reason  One of the most common arguments is  Why demand that consumers of our class create an instance for invoking this single method  while having no use for the instance afterwards  Creating an instance of a class is a very very cheap operation in most languages  so speed is not an issue  Adding an extra line of code to the consumer is a low cost for laying the foundation of a much more maintainable solution in the future  And finally  if you want to avoid creating instances  simply create a singleton wrapper of your class that allows for easy reuse - although this does make the requirement that your class is stateless  If it s not stateless  you can still create static wrapper methods that handle everything  while still giving you all the benefits in the long run  Finally  you could also make a class that hides the instantiation as if it was a singleton  MyWrapper Instance is a property that just returns new MyClass     Only a Sith deals in absolutes  Of course  there are exceptions to my dislike of static methods  True utility classes that do not pose any risk to bloat are excellent cases for static methods - System Convert as an example  If your project is a one-off with no requirements for future maintenance  the overall architecture really isn t very important - static or non static  doesn t really matter - development speed does  however   Standards  standards  standards   Using instance methods does not inhibit you from also using static methods  and vice versa  As long as there s reasoning behind the differentiation and it s standardised  There s nothing worse than looking over a business layer sprawling with different implementation methods

User · Answer

I use static classes as a means to define "extra functionality" that an object of a given type could use under a specific context. Usually they turn out to be utility classes.

Other than that, I think that "Use a static class as a unit of organization for methods not associated with particular objects." describe quite well their intended usage.

User · Answer

I do tend to use static classes for factories. For example, this is the logging class in one of my projects:

public static class Log
{
   private static readonly ILoggerFactory _loggerFactory =
      IoC.Resolve<ILoggerFactory>();

   public static ILogger For<T>(T instance)
   {
      return For(typeof(T));
   }

   public static ILogger For(Type type)
   {
      return _loggerFactory.GetLoggerFor(type);
   }
}

You might have even noticed that IoC is called with a static accessor. Most of the time for me, if you can call static methods on a class, that's all you can do so I mark the class as static for extra clarity.

User · Answer

I ve started using static classes when I wish to use functions  rather than classes  as my unit of reuse  Previously  I was all about the evil of static classes  However  learning F  has made me see them in a new light   What do I mean by this  Well  say when working up some super DRY code  I end up with a bunch of one-method classes  I may just pull these methods into a static class and then inject them into dependencies using a delegate  This also plays nicely with my dependency injection  DI  container of choice Autofac   Of course taking a direct dependency on a static method is still usually evil  there are some non-evil uses

User · Answer

I wrote my thoughts of static classes in an earlier Stack Overflow answer  Class with single method -- best approach   I used to love utility classes filled up with static methods  They made a great consolidation of helper methods that would otherwise lie around causing redundancy and maintenance hell  They re very easy to use  no instantiation  no disposal  just fire n forget  I guess this was my first unwitting attempt at creating a service-oriented architecture - lots of stateless services that just did their job and nothing else  As a system grows however  dragons be coming   Polymorphism  Say we have the method UtilityClass SomeMethod that happily buzzes along  Suddenly we need to change the functionality slightly  Most of the functionality is the same  but we have to change a couple of parts nonetheless  Had it not been a static method  we could make a derivate class and change the method contents as needed  As it s a static method  we can t  Sure  if we just need to add functionality either before or after the old method  we can create a new class and call the old one inside of it - but that s just gross   Interface woes  Static methods cannot be defined through interfaces for logic reasons  And since we can t override static methods  static classes are useless when we need to pass them around by their interface  This renders us unable to use static classes as part of a strategy pattern  We might patch some issues up by passing delegates instead of interfaces   Testing  This basically goes hand in hand with the interface woes mentioned above  As our ability of interchanging implementations is very limited  we ll also have trouble replacing production code with test code  Again  we can wrap them up  but it ll require us to change large parts of our code just to be able to accept wrappers instead of the actual objects   Fosters blobs  As static methods are usually used as utility methods and utility methods usually will have different purposes  we ll quickly end up with a large class filled up with non-coherent functionality - ideally  each class should have a single purpose within the system  I d much rather have a five times the classes as long as their purposes are well defined   Parameter creep  To begin with  that little cute and innocent static method might take a single parameter  As functionality grows  a couple of new parameters are added  Soon further parameters are added that are optional  so we create overloads of the method  or just add default values  in languages that support them   Before long  we have a method that takes 10 parameters  Only the first three are really required  parameters 4-7 are optional  But if parameter 6 is specified  7-9 are required to be filled in as well    Had we created a class with the single purpose of doing what this static method did  we could solve this by taking in the required parameters in the constructor  and allowing the user to set optional values through properties  or methods to set multiple interdependent values at the same time  Also  if a method has grown to this amount of complexity  it most likely needs to be in its own class anyway   Demanding consumers to create an instance of classes for no reason  One of the most common arguments is  Why demand that consumers of our class create an instance for invoking this single method  while having no use for the instance afterwards  Creating an instance of a class is a very very cheap operation in most languages  so speed is not an issue  Adding an extra line of code to the consumer is a low cost for laying the foundation of a much more maintainable solution in the future  And finally  if you want to avoid creating instances  simply create a singleton wrapper of your class that allows for easy reuse - although this does make the requirement that your class is stateless  If it s not stateless  you can still create static wrapper methods that handle everything  while still giving you all the benefits in the long run  Finally  you could also make a class that hides the instantiation as if it was a singleton  MyWrapper Instance is a property that just returns new MyClass     Only a Sith deals in absolutes  Of course  there are exceptions to my dislike of static methods  True utility classes that do not pose any risk to bloat are excellent cases for static methods - System Convert as an example  If your project is a one-off with no requirements for future maintenance  the overall architecture really isn t very important - static or non static  doesn t really matter - development speed does  however   Standards  standards  standards   Using instance methods does not inhibit you from also using static methods  and vice versa  As long as there s reasoning behind the differentiation and it s standardised  There s nothing worse than looking over a business layer sprawling with different implementation methods

User · Answer

For C  3 0  extension methods may only exist in top-level static classes

User · Answer

I do tend to use static classes for factories. For example, this is the logging class in one of my projects:

public static class Log
{
   private static readonly ILoggerFactory _loggerFactory =
      IoC.Resolve<ILoggerFactory>();

   public static ILogger For<T>(T instance)
   {
      return For(typeof(T));
   }

   public static ILogger For(Type type)
   {
      return _loggerFactory.GetLoggerFor(type);
   }
}

You might have even noticed that IoC is called with a static accessor. Most of the time for me, if you can call static methods on a class, that's all you can do so I mark the class as static for extra clarity.

User · Answer

I do tend to use static classes for factories. For example, this is the logging class in one of my projects:

public static class Log
{
   private static readonly ILoggerFactory _loggerFactory =
      IoC.Resolve<ILoggerFactory>();

   public static ILogger For<T>(T instance)
   {
      return For(typeof(T));
   }

   public static ILogger For(Type type)
   {
      return _loggerFactory.GetLoggerFor(type);
   }
}

You might have even noticed that IoC is called with a static accessor. Most of the time for me, if you can call static methods on a class, that's all you can do so I mark the class as static for extra clarity.

User · Answer

If you use code analysis tools  e g  FxCop   it will recommend that you mark a method static if that method don t access instance data  The rationale is that there is a performance gain  MSDN  CA1822 - Mark members as static   It is more of a guideline than a rule  really

User · Answer

I only use static classes for helper methods, but with the advent of C# 3.0, I'd rather use extension methods for those.

I rarely use static classes methods for the same reasons why I rarely use the singleton "design pattern".

User · Answer

I only use static classes for helper methods, but with the advent of C# 3.0, I'd rather use extension methods for those.

I rarely use static classes methods for the same reasons why I rarely use the singleton "design pattern".

User · Answer

I wrote my thoughts of static classes in an earlier Stack Overflow answer  Class with single method -- best approach   I used to love utility classes filled up with static methods  They made a great consolidation of helper methods that would otherwise lie around causing redundancy and maintenance hell  They re very easy to use  no instantiation  no disposal  just fire n forget  I guess this was my first unwitting attempt at creating a service-oriented architecture - lots of stateless services that just did their job and nothing else  As a system grows however  dragons be coming   Polymorphism  Say we have the method UtilityClass SomeMethod that happily buzzes along  Suddenly we need to change the functionality slightly  Most of the functionality is the same  but we have to change a couple of parts nonetheless  Had it not been a static method  we could make a derivate class and change the method contents as needed  As it s a static method  we can t  Sure  if we just need to add functionality either before or after the old method  we can create a new class and call the old one inside of it - but that s just gross   Interface woes  Static methods cannot be defined through interfaces for logic reasons  And since we can t override static methods  static classes are useless when we need to pass them around by their interface  This renders us unable to use static classes as part of a strategy pattern  We might patch some issues up by passing delegates instead of interfaces   Testing  This basically goes hand in hand with the interface woes mentioned above  As our ability of interchanging implementations is very limited  we ll also have trouble replacing production code with test code  Again  we can wrap them up  but it ll require us to change large parts of our code just to be able to accept wrappers instead of the actual objects   Fosters blobs  As static methods are usually used as utility methods and utility methods usually will have different purposes  we ll quickly end up with a large class filled up with non-coherent functionality - ideally  each class should have a single purpose within the system  I d much rather have a five times the classes as long as their purposes are well defined   Parameter creep  To begin with  that little cute and innocent static method might take a single parameter  As functionality grows  a couple of new parameters are added  Soon further parameters are added that are optional  so we create overloads of the method  or just add default values  in languages that support them   Before long  we have a method that takes 10 parameters  Only the first three are really required  parameters 4-7 are optional  But if parameter 6 is specified  7-9 are required to be filled in as well    Had we created a class with the single purpose of doing what this static method did  we could solve this by taking in the required parameters in the constructor  and allowing the user to set optional values through properties  or methods to set multiple interdependent values at the same time  Also  if a method has grown to this amount of complexity  it most likely needs to be in its own class anyway   Demanding consumers to create an instance of classes for no reason  One of the most common arguments is  Why demand that consumers of our class create an instance for invoking this single method  while having no use for the instance afterwards  Creating an instance of a class is a very very cheap operation in most languages  so speed is not an issue  Adding an extra line of code to the consumer is a low cost for laying the foundation of a much more maintainable solution in the future  And finally  if you want to avoid creating instances  simply create a singleton wrapper of your class that allows for easy reuse - although this does make the requirement that your class is stateless  If it s not stateless  you can still create static wrapper methods that handle everything  while still giving you all the benefits in the long run  Finally  you could also make a class that hides the instantiation as if it was a singleton  MyWrapper Instance is a property that just returns new MyClass     Only a Sith deals in absolutes  Of course  there are exceptions to my dislike of static methods  True utility classes that do not pose any risk to bloat are excellent cases for static methods - System Convert as an example  If your project is a one-off with no requirements for future maintenance  the overall architecture really isn t very important - static or non static  doesn t really matter - development speed does  however   Standards  standards  standards   Using instance methods does not inhibit you from also using static methods  and vice versa  As long as there s reasoning behind the differentiation and it s standardised  There s nothing worse than looking over a business layer sprawling with different implementation methods

User · Answer

This is another old but very hot question since OOP kicked in. There are many reasons to use(or not) a static class, of course and most of them have been covered in the multitude of answers.

I will just add my 2 cents to this, saying that, I make a class static, when this class is something that would be unique in the system and that would really make no sense to have any instances of it in the program. However, I reserve this usage for big classes. I never declare such small classes as in the MSDN example as "static" and, certainly, not classes that are going to be members of other classes.

I also like to note that static methods and static classes are two different things to consider. The main disadvantages mentioned in the accepted answer are for static methods. static classes offer the same flexibility as normal classes(where properties and parameters are concerned), and all methods used in them should be relevant to the purpose of the existence of the class.

A good example, in my opinion, of a candidate for a static class is a "FileProcessing" class, that would contain all methods and properties relevant for the program's various objects to perform complex FileProcessing operations. It hardly has any meaning to have more than one instance of this class and being static will make it readily available to everything in your program.

User · Answer

If you use code analysis tools  e g  FxCop   it will recommend that you mark a method static if that method don t access instance data  The rationale is that there is a performance gain  MSDN  CA1822 - Mark members as static   It is more of a guideline than a rule  really

User · Answer

If you use code analysis tools  e g  FxCop   it will recommend that you mark a method static if that method don t access instance data  The rationale is that there is a performance gain  MSDN  CA1822 - Mark members as static   It is more of a guideline than a rule  really

User · Answer

For C  3 0  extension methods may only exist in top-level static classes

User · Answer

I use static classes as a means to define "extra functionality" that an object of a given type could use under a specific context. Usually they turn out to be utility classes.

Other than that, I think that "Use a static class as a unit of organization for methods not associated with particular objects." describe quite well their intended usage.

User · Answer

For C  3 0  extension methods may only exist in top-level static classes

User · Answer

Static classes are very useful and have a place, for example libraries.

The best example I can provide is the .Net Math class, a System namespace static class that contains a library of maths functions.

It is like anything else, use the right tool for the job, and if not anything can be abused.

Blankly dismissing static classes as wrong, don't use them, or saying "there can be only one" or none, is as wrong as over using the them.

C#.Net contains a number of static classes that is uses just like the Math class.

So given the correct implementation they are tremendously useful.

We have a static TimeZone class that contains a number of business related timezone functions, there is no need to create multiple instances of the class so much like the Math class it contains a set of globally accesible TimeZone realated functions (methods) in a static class.

User · Answer

I ve started using static classes when I wish to use functions  rather than classes  as my unit of reuse  Previously  I was all about the evil of static classes  However  learning F  has made me see them in a new light   What do I mean by this  Well  say when working up some super DRY code  I end up with a bunch of one-method classes  I may just pull these methods into a static class and then inject them into dependencies using a delegate  This also plays nicely with my dependency injection  DI  container of choice Autofac   Of course taking a direct dependency on a static method is still usually evil  there are some non-evil uses

User · Answer

I wrote my thoughts of static classes in an earlier Stack Overflow answer  Class with single method -- best approach   I used to love utility classes filled up with static methods  They made a great consolidation of helper methods that would otherwise lie around causing redundancy and maintenance hell  They re very easy to use  no instantiation  no disposal  just fire n forget  I guess this was my first unwitting attempt at creating a service-oriented architecture - lots of stateless services that just did their job and nothing else  As a system grows however  dragons be coming   Polymorphism  Say we have the method UtilityClass SomeMethod that happily buzzes along  Suddenly we need to change the functionality slightly  Most of the functionality is the same  but we have to change a couple of parts nonetheless  Had it not been a static method  we could make a derivate class and change the method contents as needed  As it s a static method  we can t  Sure  if we just need to add functionality either before or after the old method  we can create a new class and call the old one inside of it - but that s just gross   Interface woes  Static methods cannot be defined through interfaces for logic reasons  And since we can t override static methods  static classes are useless when we need to pass them around by their interface  This renders us unable to use static classes as part of a strategy pattern  We might patch some issues up by passing delegates instead of interfaces   Testing  This basically goes hand in hand with the interface woes mentioned above  As our ability of interchanging implementations is very limited  we ll also have trouble replacing production code with test code  Again  we can wrap them up  but it ll require us to change large parts of our code just to be able to accept wrappers instead of the actual objects   Fosters blobs  As static methods are usually used as utility methods and utility methods usually will have different purposes  we ll quickly end up with a large class filled up with non-coherent functionality - ideally  each class should have a single purpose within the system  I d much rather have a five times the classes as long as their purposes are well defined   Parameter creep  To begin with  that little cute and innocent static method might take a single parameter  As functionality grows  a couple of new parameters are added  Soon further parameters are added that are optional  so we create overloads of the method  or just add default values  in languages that support them   Before long  we have a method that takes 10 parameters  Only the first three are really required  parameters 4-7 are optional  But if parameter 6 is specified  7-9 are required to be filled in as well    Had we created a class with the single purpose of doing what this static method did  we could solve this by taking in the required parameters in the constructor  and allowing the user to set optional values through properties  or methods to set multiple interdependent values at the same time  Also  if a method has grown to this amount of complexity  it most likely needs to be in its own class anyway   Demanding consumers to create an instance of classes for no reason  One of the most common arguments is  Why demand that consumers of our class create an instance for invoking this single method  while having no use for the instance afterwards  Creating an instance of a class is a very very cheap operation in most languages  so speed is not an issue  Adding an extra line of code to the consumer is a low cost for laying the foundation of a much more maintainable solution in the future  And finally  if you want to avoid creating instances  simply create a singleton wrapper of your class that allows for easy reuse - although this does make the requirement that your class is stateless  If it s not stateless  you can still create static wrapper methods that handle everything  while still giving you all the benefits in the long run  Finally  you could also make a class that hides the instantiation as if it was a singleton  MyWrapper Instance is a property that just returns new MyClass     Only a Sith deals in absolutes  Of course  there are exceptions to my dislike of static methods  True utility classes that do not pose any risk to bloat are excellent cases for static methods - System Convert as an example  If your project is a one-off with no requirements for future maintenance  the overall architecture really isn t very important - static or non static  doesn t really matter - development speed does  however   Standards  standards  standards   Using instance methods does not inhibit you from also using static methods  and vice versa  As long as there s reasoning behind the differentiation and it s standardised  There s nothing worse than looking over a business layer sprawling with different implementation methods

User · Answer

I use static classes as a means to define "extra functionality" that an object of a given type could use under a specific context. Usually they turn out to be utility classes.

Other than that, I think that "Use a static class as a unit of organization for methods not associated with particular objects." describe quite well their intended usage.

User · Answer

I do tend to use static classes for factories. For example, this is the logging class in one of my projects:

public static class Log
{
   private static readonly ILoggerFactory _loggerFactory =
      IoC.Resolve<ILoggerFactory>();

   public static ILogger For<T>(T instance)
   {
      return For(typeof(T));
   }

   public static ILogger For(Type type)
   {
      return _loggerFactory.GetLoggerFor(type);
   }
}

You might have even noticed that IoC is called with a static accessor. Most of the time for me, if you can call static methods on a class, that's all you can do so I mark the class as static for extra clarity.

User · Answer

For C  3 0  extension methods may only exist in top-level static classes

User · Answer

If you use code analysis tools  e g  FxCop   it will recommend that you mark a method static if that method don t access instance data  The rationale is that there is a performance gain  MSDN  CA1822 - Mark members as static   It is more of a guideline than a rule  really

User · Answer

Based on MSDN    You cannot create the instance for static classes If the class declared as static  member variable should be static for that class Sealed  Cannot be Inherited  Cannot contains Instance constructor Memory Management   Example  Math calculations  math values  does not changes  STANDARD CALCULATION FOR DEFINED VALUES

User · Answer

Static classes are very useful and have a place, for example libraries.

The best example I can provide is the .Net Math class, a System namespace static class that contains a library of maths functions.

It is like anything else, use the right tool for the job, and if not anything can be abused.

Blankly dismissing static classes as wrong, don't use them, or saying "there can be only one" or none, is as wrong as over using the them.

C#.Net contains a number of static classes that is uses just like the Math class.

So given the correct implementation they are tremendously useful.

We have a static TimeZone class that contains a number of business related timezone functions, there is no need to create multiple instances of the class so much like the Math class it contains a set of globally accesible TimeZone realated functions (methods) in a static class.

User · Answer

I only use static classes for helper methods, but with the advent of C# 3.0, I'd rather use extension methods for those.

I rarely use static classes methods for the same reasons why I rarely use the singleton "design pattern".

[c#] When to use static classes in C#

The answer is

Examples related to c#

Examples related to class

Examples related to static

Tags