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\)]

Re: Singleton pattern vs Class with purely static members

"Atul Malaviya" <atul.malaviya@ gmail.com> a écrit dans le message de news:
1120808886.9858 37.199560@g43g2 00...legr oups.com...
[color=blue]
> When will one use a singleton pattern and when a class with purely
> static members?[/color]

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]

Re: Singleton pattern vs Class with purely static members

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

[Hans Kesting]

Re: Singleton pattern vs Class with purely static members

Joanna Carter (TeamB) wrote:[color=blue]
> "Atul Malaviya" <atul.malaviya@ gmail.com> a écrit dans le message de
> news: 1120808886.9858 37.199560@g43g2 00...legr oups.com...
>[color=green]
>> When will one use a singleton pattern and when a class with purely
>> static members?[/color]
>
> 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[/color]

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]

Re: Singleton pattern vs Class with purely static members

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]

Re: Singleton pattern vs Class with purely static members

Atul Malaviya wrote:[color=blue]
> 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?
>[/color]

"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.
[color=blue]
> 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.[/color]

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 \)]

Re: Singleton pattern vs Class with purely static members

Hi,

[color=blue]
>
> 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.[/color]

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 \)]

Re: Singleton pattern vs Class with purely static members

Hi,
[color=blue]
>
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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