Design Decision - Static vs. Non Static Classes

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

Hi,

"Smithers" <A@B.comwrote in message
news:eg%236E%23C5HHA.600@TK2MSFTNGP05.phx.gbl...

Quote:

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

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

"Smithers" <A@B.comwrote in message
news:eg%236E%23C5HHA.600@TK2MSFTNGP05.phx.gbl...

Quote:

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
>

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/

"Richard Lewis Haggard" <HaggardAtWorldDotStdDotComwrote in message
news:O$nurdD5HHA.4584@TK2MSFTNGP03.phx.gbl...

Quote:

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
>
>
"Smithers" <A@B.comwrote in message
news:eg%236E%23C5HHA.600@TK2MSFTNGP05.phx.gbl...

Quote:

>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
>>

>
>

clintonG wrote:

Quote:

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.

On 2007-08-21, Smithers <A@B.comwrote:

Quote:

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)

--
Kind regards,
Tim Van Wassenhove <url:http://www.timvw.be/>

Tim Van Wassenhove <timvw@newsgroup.nospamwrote:

Quote:

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.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Design Decision - Static vs. Non Static Classes

re: Design Decision - Static vs. Non Static Classes

re: Design Decision - Static vs. Non Static Classes

re: Design Decision - Static vs. Non Static Classes

re: Design Decision - Static vs. Non Static Classes

re: Design Decision - Static vs. Non Static Classes

re: Design Decision - Static vs. Non Static Classes

Similar C# / C Sharp bytes

/bytes/development

/bytes/it

/bytes/about