CODEWITHSUNDEEP
c#.netstatic
King King
King King

Reputation: 63387

In which case shouldn't I use static members in a class?

I have to ask this question because I feel that only experienced programmers can know the pros and cos of static members in a class. I've read books explaining about static members, I've also used many static members in my project according to my points of view.

As I understand, if there is some class which is used only 1 time in my project, I mean there is no need to create some or many instances, I should make all its members static, especially static methods. Is this true? This has another benefit because of that calling to static members can be done easily without creating new instances or passing instances between our classes.

Using static members in my projects doesn't show me what's wrong with it, my project seems to run normally, of course I don't mean I like using static members and use it randomly, frequently (as I explained my point of view above). I think there may be some pros and cons of static members (that I don't know) and I would like to know from your experience. Please share with me.
Thank you!

Upvotes: 6

Views: 2269

Answers (4)

d.moncada
d.moncada

Reputation: 17402

Check out the following posts:

As I understand, if there is some class which is used only 1 time in my project, I mean there is no need to create some or many instances, I should make all its members static, especially static methods. Is this true?

It depends. I believe that static classes are good if you want to access them globally throughout your application (ie, utility classes, helper functions, etc).

Use a static class to contain methods that are not associated with a particular object. For example, it is a common requirement to create a set of methods that do not act on instance data and are not associated to a specific object in your code. You could use a static class to hold those methods.

Keep in mind that declaring a class static allows it to stay in memory for the lifetime of the application. This means if the static class is only used once, it will still remain in memory even after it is not needed/will be used again. Instead, if the class is only used once, you may be better off creating a regular class instance so that GC will clean up after you're done using it.

Upvotes: 5

Dylan Smith
Dylan Smith

Reputation: 22255

My main problem with statics is that it makes it really hard to do polymorphism (replace one thing with another at run time). The place you often want to do this is when writing tests, I want to replace the FileManager class with a MockFileManager. If I'm using a non-static class, I just use interfaces to achieve polymorphism, and hopefully I'm using IoC pattern and I can pass in my mock implementation in place of the real one (yay polymorphism!).

However, if my FileManager class is all static, it makes it really hard to replace it with something else dynamically.

Note: There are Code Analysis rules which tell you to make things static for perf reasons. I turn those rules off.

Upvotes: 3

NDJ
NDJ

Reputation: 5194

As I understand, if there is some class which is used only 1 time in my project, I mean there is no need to create some or many instances, I should make all its members static, especially static methods. Is this true?

It can be - there are times when you want an instance and it can't be static because it implements an interface for example - in which case you'd use the singleton pattern.

Static methods can be useful and if your class doesn't contain state then the likelihood is should be fine as a static class.

Upvotes: 4

phadaphunk
phadaphunk

Reputation: 13313

To quote someone who can explain it way better than me :

The abuse of static classes can be considered bad practice. But so can the abuse of any language feature.

I make no distinction between a non-static class with only static methods and a static class. They are effectively the same thing, except that static classes allow the compiler to enforce the developers intent (no instantiating this class, convenient syntax for accessing its functionality, etc).

A proliferation of "Helper" classes can get you into trouble (design, maintainability, readability, discoverability, other-abilities...). No argument here. But can you argue that a "Helper" class is never appropriate? I doubt it.

Indeed, responsible use of static classes can have great benefits to your code:

The Enumerable static class provides a set of extension methods most of us have come to love. They are a logical set of functionality / business logic that isn't related a instance of any particular type. Services provided by the environment/context: eg Logging, Configuration (sometimes) Others (that I can't think of at the moment :)) So no, in general its not bad practice. Just use them wisely...

As for myself, I use them when I need to use them it doesn't really matter if it seems like a bad practice or not.

Rule of thumb ? If you know why you should use static and can explain it then you should use it.

Upvotes: 2

Related Questions