Singleton pattern vs Class with purely static members

[Atul Malaviya]

>From a design/usability perspective.

When will one use a singleton pattern and when a class with purely
static members?

What are the pros and cons? I have inherited a code base which is full
of both these and I am a bit confused on this count.

Singleton insures one object of a class in the application. A class
with purely static members and a private constructor also strives to
achieve the same.

The only difference I can think of is that in the second case we are
not creating an object so we are saving some memory space. Which,in my
opinion is not a decent enough reason to decide against one of the
options.

Where will we use one and not the other? Any inputs/insights will be
appreciated.

[Joanna Carter \(TeamB\)]

"Atul Malaviya" <at***********@ gmail.com> a écrit dans le message de news:
11************* *********@g43g2 00...legr oups.com...

When will one use a singleton pattern and when a class with purely
static members?

I find that the only time I would use a "created" Singleton as opposed to a
static class, is when resources that are expensive need to be released as
soon as they are finished with whereas, with a static class, any state
fields are kept in memory until the program quits.

Joanna

--
Joanna Carter
Consultant Software Engineer

[Atul Malaviya]

Thanks for the prompt reply Joanna.
That pretty much clears the air and gives me a defining line.

[Hans Kesting]

Joanna Carter (TeamB) wrote:

"Atul Malaviya" <at***********@ gmail.com> a écrit dans le message de
news: 11************* *********@g43g2 00...legr oups.com...

When will one use a singleton pattern and when a class with purely
static members?

I find that the only time I would use a "created" Singleton as
opposed to a static class, is when resources that are expensive need
to be released as soon as they are finished with whereas, with a
static class, any state fields are kept in memory until the program
quits.

Joanna

For an asp.net application, I use it precisely the other way around:
Singleton for things I want to keep in memory (application wide), such
as configuration data
Static methods (*without* using static members) if I want to clean up
immediately.

If I understand correctly, a singleton is created once "somewhere"
in the lifetime of the application and usually never destroyed, until the
application ends. The data it contains might be refreshed.
Hans Kesting

[Atul Malaviya]

Hans Kesting said:
"Static methods (*without* using static members) if I want to clean up
immediately."

What will an static method cleanup then? Because it can access only
static members. Can you please explain it a bit more?

In case of singleton pattern if the object has been Garbage collected
then a new one will be created and passed back(sort of refreshing the
data). The same can be achieved in case of purely static member class
by implementing a static method which will clean up the required static
members.

[Hans Kesting]

Atul Malaviya wrote:

Hans Kesting said:
"Static methods (*without* using static members) if I want to clean up
immediately."

What will an static method cleanup then? Because it can access only
static members. Can you please explain it a bit more?

"only static members", it can only access static members of *it's own class*
(as there is no instance)
There is no-one preventing you from instantiating local variables, which
might require cleanup.
In case of singleton pattern if the object has been Garbage collected
then a new one will be created and passed back(sort of refreshing the
data). The same can be achieved in case of purely static member class
by implementing a static method which will clean up the required
static members.

A singleton should never be GC'ed, as there is a reference to it (it holds
a static reference to itself)

Hans Kesting

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

Hi,

I find that the only time I would use a "created" Singleton as opposed to
a
static class, is when resources that are expensive need to be released as
soon as they are finished with whereas, with a static class, any state
fields are kept in memory until the program quits.

No necessarily, in both cases you can create methods to dispose the
resources as needed.
IMO the main difference is that with a singleton pattern the code using it
has no knowledge that a single instance exist. the code treat the instance
as any other instance. The "singleton" part is transparent. If the developer
later decide to have more than one instance , let's say one instance per
processor just to put an example, the calling code need NO recompiling nor
change.

In the case of a static class the calling code call the methods using the
type , not an instance so if any change happen the calling code needs to be
modified and recompiled.

Those are subtle but important differences !

I use static (either classes or member ) when there is clear that it does
not form part of an instance. The best example is the Math class.

I use a singleton wherever an instance is needed or is what makes sense.
HTH,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

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

Hi,

For an asp.net application, I use it precisely the other way around:
Singleton for things I want to keep in memory (application wide), such
as configuration data
Static methods (*without* using static members) if I want to clean up
immediately.
They are called stateless , you can get the same with any type, you do not
need to be static, but this is a VERY good place where to use static, if you
do not need to keep a state then your method may have more context in a type
wide, than in an instance.
If I understand correctly, a singleton is created once "somewhere"
in the lifetime of the application and usually never destroyed, until the
application ends. The data it contains might be refreshed.

No really you can use either approach and create a method to get the
internal state to its original one, with this you refresh your instance/type
as needed. read my other post for the real difference between them.
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation