Static versus Singleton versus seperate Instantiations...

[Dan Bass]

while working in a probject, you realise that some string handling stuff
you're implementing has occurred before in the same project. So being a good
developer, you factorise the commonalities out and into some "StringMethods"
type class...

Would you:
- create this object and use that instance each time to access the methods
you need
- use a singleton structure, so that only one instance is ever created
- use public statics, so that you never need to create a host instance in
the first place

Would the same principle apply to global constants?

I've been using public statics since the move to c# and wondered if this was
the best approach.

Thanks for your time.

Daniel.

 

[Dennis Myrén]

I've been using public statics since the move to c# and wondered if this
was the best approach.

Yes, I would say using static methods is definitely the best approach.

 

[David Markle]

Dan:

Good question. Use public (or internal) static methods instead of a
Singleton. Singletons would be the choice if you had a class that actually
needed to sit around in memory and maintain the state of something (for
example, if you wanted something to act kind of like an in-process "server".

-Dave

 

[Jeff Louie]

Dan.... Correct me if I am wrong , but I must assume that the cost of a
static
method and a singleton method is going to be similar except maybe a
pointer
to this in the stack frame for a singleton. As best I understand it, a
new "stack
frame" is generated for every call to a static method, and this "stack
frame"
contains a copy of the method arguments and stores any new objects
created
in the static method.

My understanding is to use static methods unless you want to support a
level
of indirection provided by the SingletonPattern.

Regards,
Jeff

- use a singleton structure, so that only one instance is ever created

- use public statics, so that you never need to create a host instance
in
the first place<