This question already has answers here:
In C#, what is the purpose of marking a class static?
(5 answers)
Closed 4 years ago.
While learning about static classes, I went through many forums as per my understanding I got to know that static class members can be accessed directly using class name and hence not required to create object of that class which in turn helps save memory and faster execution of program.
So my question is if this is the case then why not always use static class over normal class.
I know my question may be little weird, also I may be wrong with the concepts. Please if any one can explain this in detail with example. would be great help.
A static class can not be instantiated. E.g. you can't use new to create an object of that class in C#.
There are many situations where you might want to create multiple objects of a class.
Related
This question already has answers here:
How to restrict class members to only one other class
(6 answers)
Closed 1 year ago.
Is it possible to have a class that is available just to other specific class, and inaccessible to the "rest" of the code?
Thank you.
For one class, you make nest one class inside another. If you need to later expand this, you can do it by breaking the Solution up among different Projects (dlls), marking a class internal, and using the [InternalVisibleTo] attribute.
This question already has answers here:
Extension methods require declaring class to be static
(1 answer)
Why are extension methods only allowed in non-nested, non-generic static class?
(3 answers)
Closed 9 years ago.
I mean, I'm pretty sure it is a good habit anyway, but are there any technical/conceptual reasons why this is enforced by the compiler? Or is it enforcing aesthetics only?
There are no reasons for this behavior below the C# layer. Starting with the IL layer extension methods and static classes do not exist (except for either unimportant changes or custom attributes).
It is a choice the language designers made, supposedly for code clarity. It does not have to be this way for any fundamental reason.
There are other similar restrictions as well. For example you can't have extensions defined in nested classes.
For my understanding this is a conceptual move.
The static class acts like a pure container for methods and itself does not represents the object, and the extension method by itself is the method that only processes the input and does not acts like a part of the objects behavior.
That is why I think they are very similar by its nature in the C# and probably that is why they where linked together by the language.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why seal a class?
I haven't seen a lot of classes with this modifier, however I'm wondering in which kind of scenarios this would be useful.
In case you do not wand anyone to extend a class.
Classic example is a String class, it's self-sufficient and implements flyweight pattern, that might be easily destroyed if anyone could overwrite it's methods/properties.
You want to use the sealed class if you provide your API that doesn't need to be changed, for any of above reasons.
This question already has answers here:
What is better? Static methods OR Instance methods
(7 answers)
Closed 9 years ago.
When its recommended to use a private static method instead of a private [instance] method?
EDIT:
i am looking for a good (or best practice) about that .i am wondering Is this technic used by microsoft or not?does anybody know something about that ? i coudnt find any blog ,article or sample source code that explains this topic.
any help would be highly appreciated.
Static word in the beginning of the method declaration, basically is a sign of stateless, so what is happening inside is a pure action, or at least should be.
If you want to use private static: use it like API functions of your class that just make some calculations/reports... and not change the actual state of the object, which basically is done by instance methods.
This is an expected way of implementing, which doens't mean that is mandatory, but as it's expected, it will help other developers understand your code, and help understand code to you after a couple of years, when you will come back to your project and already have forgot everything.
Regards.
This question already has answers here:
Closed 13 years ago.
Duplicate
Should C# methods that can be static be static?
Please forgive me if this question seems elementary - I'm looking over some source code that otherwise looks pretty good, but it's raised some questions...
If a given class has no member data - i.e. it doesn't maintain any sort of state, are there any benefits in not marking that class as a static class with static methods?
Are there any benefits in not marking methods which don't maintain state as static?
Thanks!
EDIT: Since someone brought it up, the code I'm looking at is written in c#.
Yes. I can think of some reasons:
Ease of mocking and unit testing
Ease of adding state
You could pass it around (as an interface or something)
I would say there is a benefit to making them static methods of the class, and on top of that making the class abstract. That way, it's clear to the programmer that this class was never intended to be instantiated and the methods are still available.
There might be a benefit in leaving methods that don't change state non-static, if you intend (or think you might intend) to inherit from the class and override those methods with code that does change state. Though in that case it really should be an abstract class.
If a class doesn't maintain any state, doesn't have any instance methods, and could be implemented entirely with class methods, I usually take a long hard look at whether its behaviors would in fact make more sense somewhere else. I find they usually seem to have a lot of methods along the lines of doSomethingWithItem(Item item), which would make more sense as an instance method in Item.
Yeah, I know this doesn't answer your question, but I think others have covered that pretty well already, and I wanted to get another perspective out there.