Assembly creation guidelines

Question

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?

Answer 1

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

Answer 2

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] static fields 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
• Truly global, shared runtime data...its just simpler than using IoC and an extra type