Related
I can imagine the first reaction when you read the title of my question: "How can you have such a high reputation here and ignore what a class is?"
My point is the following: until now I have always worked with C++, Delphi, Java, ... and there it's quite simple: a class is a type definition of an object. You need to reserve some space in memory to start using it (hence the constructor) and afterwards, don't forget to free that memory (if your programming language does not support garbage collection).
Today, however, I had a problem concerning type definitions and constants in C#, and I fell on this URL, mentioning such pieces of source code:
class Calendar1
{
public const int Months = 12;
}
In order to use this, you just need to do:
using Calendar1;
And you can use Months as a constant.
But here's my question: where's the constructor? If this class is the type definition of an object, which object are we talking about?
So, if I understand correctly, C# is based on the idea "Everything is a class", but in order to make this work, the C# inventors have extended the definition of a class, so now we get (C# definition):
A class is one of the following:
a type definition for an object. In that case, a constructor is needed for creating the object.
...
Can somebody finish the definition?
This is a pretty common practice in C#. Classes are often used to create "sacks" to hold constants, or commonly as a entity or dto object. These are usually made without a user defined constructor. If a class does not have a constructor, one is defined at compile time which amounts to an empty constructor:
public Calendar1()
{
}
This answer goes into much further detail:
C# class without constructor
You don't need this using. using is to make namespaces available.
A constant is static. This means that it is not an instance member but a member of the type. Thus, you can access it through the type name: Calendar1.Months or, with a using static Calendar1; just with Months.
In C# a class implicitly creates a parameterless public constructor, if you don't declare one explicitly.
When you are creating a instance of a class you are allocating memory (using the keyword new)
Constants are created not in runtime, they are created in compile time and stored in the assembly metadata. So when you are accessing a constant you will be not accessing an instance of a class - you will be accessing the constant from the metadata directly.
Have a look at this post:
How are C# const members allocated in memory?
This question already has answers here:
Class with single method -- best approach?
(15 answers)
Closed 8 years ago.
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?
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.
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!
For C# 3.0, extension methods may only exist in top-level static classes.
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...
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.
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.
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).
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.
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.
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".
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]
A couple of questions re static classes. Some of this is from stuff I have read a while ago so I want to dispell any myths.
I know that if I need one instance of a class, eg like to represent one company (ie company details), the class can be static. Why do I need multiple identical instances?
However:
1) Can the choice of parameters in the methods of a class (ie the type or whether its an instance class/interface etc) , instance or otherwise, affect the decision to make a class static or not? So if I provide an instance object as a parameter (e.g. myMethod(new Car()) ), or anything, can this have any influence on whether to make the class static or not? I read a while back that this can, so I am trying to dispell a myth.
2) If the static class does not use another class's state, does this have any bearing on making a class static?
IE a static class which contains a field, and that field is used within the class's ownn methods.
I also read a post on here about static and a member said that if the class does not contain "repeatable" functionality, it could be made static. What does repeatable mean in this context?
Thanks
No, the type of parameter is wholly irrelevent to the class being static.
No, a method consuming state (or not) has no bearing on whether the method should be static.
I suspect "repeatable" means potentially polymorphic with subclasses and method overriding.
In sum, make the method (or class) static if it will never consume or modify state on its own instance. In other words, if it doesn't make use of this (either explicitly or implied) then it should probably be made static.
Three reasons to make an object not static:
Your object will need to be set to a newly initialized state more than once. You could write a method to do the reinitialization, but Note that although static classes can have a constructor (which I believe is not called until the first reference to a member of the static class triggers the class to be loaded), you can't call it run-time.
You might want to have a 'memento' copy of the object to undo to when the user cancels editing a 'work' copy.
The static object might be accessed from multiple instantiated objects at the same time. I have seen problems from an ASP.NET web application where a static object was used to store user and state data during page load processing that would have been shared between simultaneous page requests from different users.
1) It cannot. Static methods and instance methods can have the very same signatures, concerning argument types.
2) It does not.
Repeatable: This probably refers to the state stored in instances of the class. If you need a storage for a given program state (say, a score) only once, you can use a static class with static fields. If you need that state several times (say, another score for each player), you use instance fields because you can then create as many instances of your class as you need (in this case, as many instances as there are players).
The simple sum-up in my opinion: If it makes sense for all members of a class to be static, then you should mark the class as static. There's not really anything complicated going on here, it's as simple as that.
L2SQL generates entities with a default a parameterless constructor. This CANNOT be changed as it is needed to materialise the object.
However, if my object can only be created with certain values initialised how would I go about hiding the parameterless constructor so that a consumer only sees a constructor with parameters?
1) I can create another partial class of the same name and add my new constructor there but the consumer now simply has two options to create an instance of my class. The parameterless constructor is still visible.
2) Use interfaces. It is not possible to create an interface that defines constructors.
How do people approach this as it looks like an issue that would occur a lot.
If I understand you correctly, you want to prevent other users of the class from constructing one from the parameterless constructor, but still allow Linq2SQL to use it (as it must do so).
Luckily you are wrong when you say the default parameterless constructor cannot be changed. If you change the constructor of a Linq2SQL entity class to be private, then it will still be called by Linq2SQL as it uses reflection, and it is possible to call a private constructor if you use reflection. (Incidentally, other changes to the constructor can also be done with Linq2SQL).
Of course, the other users of the class can also use reflection to call that private constructor and create a class in a private state, but that is true of all .NET classes (and indeed applies elsewhere - e.g. it's often not hard to usurp the privacy of C++ classes, though there is no implementation-independent guarantee either way). But then it's pretty much always possible to use reflection to mess a class up; encapsulation is a mechanism to ensure correctness, not security. (But security restrictions on what code can use reflection then builds security on top of that less guarantee).
This question already has answers here:
Class with single method -- best approach?
(15 answers)
Closed 8 years ago.
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?
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.
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!
For C# 3.0, extension methods may only exist in top-level static classes.
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...
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.
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.
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).
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.
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.
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".
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]