Design Decision - Static vs. Non Static Classes

[Smithers]

In consideration of a "Utilities" class that contains methods intended to be
used amongst multiple projects...

Is there any general consensus on whether such a class should be static? I
have traditionally and somewhat thoughtlessly created these sorts of classes
as static... but now that I'm refactoring a number of apps written over the
past few years I'd like to make a good decision on this particular issue.

And yes - I know there is no "right vs. wrong" way to go here - so I'd
appreciate some considerations both for and against static classes (in the
case of utilities or DAL).

Thanks

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

In consideration of a "Utilities" class that contains methods intended to
be used amongst multiple projects...

Is there any general consensus on whether such a class should be static? I
have traditionally and somewhat thoughtlessly created these sorts of
classes as static... but now that I'm refactoring a number of apps written
over the past few years I'd like to make a good decision on this
particular issue.

Well, take a look at how those "utilities" classes are defined in the
framework, take a look at for example Math, File, Directory, Environment,
etc

 

[Richard Lewis Haggard]

It depends. If the class functions can be used as standalone with no
internal data that has to hang around then static works well. On the other
hand, if the class will have data members that will hang on to information
between method calls then static is probably not such a good idea.
--
Richard Lewis Haggard
General: www.Haggard-And-Associates.com

Please come visit here for a couple thousand good giggles!:
www.haggard-and-associates.com/Humor/humor.htm

 

[clintonG]

And how would the use of delegates affect the use of the utility class
members?

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/

 

[Chris Shepherd]

And how would the use of delegates affect the use of the utility class
members?

From the perspective of keeping everything involved in the process
inside the method, I don't really see any issues doing it this way -- as
long as the delegate itself follows the same rule and only tries to act
on things it has been provided. You might get into threading issues if
you try and do anything beyond that.

Chris.

 

[not_a_commie]

The only time I would use a static class is if it had absolutely no
dependencies on other static classes (not counting System.*). In my
application I have several static classes. Most of them are math or
Win32 libraries. The most significant static class is the
"ServiceRegistry" class, which basically contains a collection of
(possibly singleton) classes. The ServiceRegistry gets initialized
first in my application, loading all the other application services
and plugins that are listed in a configuration file. This way the
various services and plugins can specify what other services and
plugins they depend on. The ServiceRegistry can load them all in order
of dependencies and call their Init functions in that order as well.

 

[Tim Van Wassenhove]

Is there any general consensus on whether such a class should be static? I
have traditionally and somewhat thoughtlessly created these sorts of classes
as static... but now that I'm refactoring a number of apps written over the

How do you want to test the class? And how would you test stuff that
uses these static methods? (Mocking seems hard to achieve)

 

[Jon Skeet [C# MVP]]

How do you want to test the class? And how would you test stuff that
uses these static methods? (Mocking seems hard to achieve)

Static classes typically have no dependencies, or you specify them as
method parameters (which can be mocked appropriately).

A lot of the time you don't need to mock to test static classes anyway
though: if I have a static StringHelper class which has a method
declared as:

static string Reverse(string original)

then there's no need to mock anything in order to test it thoroughly.

Jon

 

[Tim Van Wassenhove]

Static classes typically have no dependencies, or you specify them as
method parameters (which can be mocked appropriately).

A lot of the time you don't need to mock to test static classes anyway
though: if I have a static StringHelper class which has a method
declared as:

static string Reverse(string original)

then there's no need to mock anything in order to test it thoroughly.

Testing the static method itself isn't that hard. Testing methods that
use this static method is what can become difficult.

Eg:

static class X
{
public static int GetCount() { return 5; }
}

class Y
{
public int DoSomething()
{
int count = X.GetCount();
return count - 3;
}
}

What if X.GetCount() performs a cpu intensive operation? or queries a
database? Do you really want to execute that method in order to test
Y.DoSomething?

 

[Jon Skeet [C# MVP]]

Testing the static method itself isn't that hard. Testing methods that
use this static method is what can become difficult.

Indeed, if it's doing something complicated or using an external
resource. In that case it's often worth encapsulating the behaviour in
an interface and using dependency injection or a replacable factory
etc.

Most static classes I've written haven't included such behaviour,
however - they've been simple utility methods.