Is there any rule of the thumb as to the number of static functions you can have in an assembly?
How do you recognize if a function needs to be static v/s a function that doesn't need to be static?
+2
A:
Well, there is no rule of thumb - that comes down to the design argument. If you were to listen to FxCop, a method is elligible to be static if it doesn't work on instance members of the class...
I prefer to take the age-old definition, the method should be static if it is shared across the type and not specific to an instance of the type.
This link contains a "When to use" section:
http://msdn.microsoft.com/en-us/library/79b3xss3(VS.80).aspx
Adam
2010-07-27 20:56:46
Thanks for the link.
abhi
2010-07-27 21:15:49
+1
A:
Generally speaking, with the advent of DI and IoC containers that provide lifestyle control over components, I try to keep my use of static to an absolute, bare minimum. With 'singleton' components managed by an IoC container, the value and use of static classes and/or functions diminishes to vanishing levels.
That said, there is not really a limit on how many static types or members you can have in an assembly. Static members of a type are stored on something called loader heaps, rather than the normal GC heap, by the CLR, and these heaps start out fairly small (around 32k I believe.) Given that, it would probably take many thousands of static classes and/or methods to fill up the loader heap.
Here are some of the very few ways I still use static members or classes:
[ThreadStatic] staticfields used in classes that must provide thread-singleton behavior- static constructors in my .NET confiugration classes like
ConfigurationSection,ConfigurationElement, etc.- I've begun replacing this style of configuration class construction to simply using the
[ConfigurationProperty()]attributes, which is simpler and generally cleaner, although it does incur a very small amount of additional overhead
- I've begun replacing this style of configuration class construction to simply using the
- Truly global, shared runtime data...its just simpler than using IoC and an extra type
jrista
2010-07-27 21:00:47
The question asks about static functions, not static fields. I agree that static fields should be as few as possible, with 0 as the ideal. But static methods are a completely different issue!
Jeffrey L Whitledge
2010-07-27 21:10:41
My mention of static fields were only an indication of the very few cases where I use statics of any kind, nothing more.
jrista
2010-07-27 21:30:11
I've been thinking about this, and I'm not at all certain that this holds up. I understand that, when you want to be able to specify the implementation at startup, you need to have an instance. Having said that, there are certainly cases where this is not a needed or even desirable features, and still other cases where we do want to have an instance but don't want to show it. I'll give an example:
Steven Sudit
2010-07-28 13:44:29
Let's say we have a Logger class which has a singleton of type ILogger. The static constructor gets the typename of the ILogger implementation and uses it. We could expose this singleton, forcing callers to say `Logger.Singleton.Log("Ok");`. On the other hand, we could write a few static pass-through methods to allow a more natural `Logger.Log("Ok");"`. Isn't this better?
Steven Sudit
2010-07-28 13:48:15
@Steven: I wouldn't use either method. I would inject an instance of the ILogger interface via an IoC container, and let the container manage instance creation of the logger. Some logger frameworks require an instance per class, others provide a single instance that may be used by everything. Regardless, thats a cross-cutting concern, and I don't want my code to have to deal with it at all. I just want to be able to use an instance of ILogger, regardless of how it was created or where it came from, and do logging. An IoC container takes care of that for me. Does that make sense?
jrista
2010-07-28 23:16:42
I think we're talking past each other. My point is that, even if we use IoC and a singleton, we don't have to *expose* the functionality as a singleton; we can wrap it in static methods. If we need one instance per, then it would just have to be thread-static.
Steven Sudit
2010-07-29 00:27:52
@Steven: We may be talking past each other...however, I think were talking about entirely alternative approaches. Unless I am missing something, one would either choose to use DI with an IoC container, **or** they would choose to use statics. Even with statics...if you want the freedom to swap out logging frameworks, you still need some way of *configuring* which framework to instantiate when you call your static methods on say a Logger class. That brings us right back around to DI of some kind again, which leaves the statics as extra heft that we don't really need in the first place.
jrista
2010-07-29 15:55:01
Yes, you're missing something: my precise point is that you don't have to choose. You can implement a singleton whose implementation is selected at startup *and* you can expose its `Log` method as the static `Logger.Log`. The static is not "extra heft", it's syntactic sugar. It allows the user not to have to consider our complex infrastructure and instead call in the most direct possible fashion.
Steven Sudit
2010-07-29 19:40:13
+1
A:
I thought the rule of thumb is to make it static if you can. In other words, if a method needs to access instance fields, then it can't be static. Otherwise, it should be.
Steven Sudit
2010-07-27 21:06:36