[abstract question] usage of Singleton pattern with C#

[Faust]

Hi,

i'm implementing a singleton class, and changing non static to static
functions, vars, properties one after another I discover all my
implementation can be done as static in the class so there's no need of
singleton instance to use it.

to extend thinking, I wonder in which cases the singleton pattern is
still useful (in C# at least) as, AFAIK, everything we declare in a
class to be instance dependant can be declared static
even constructor and event handlers have their static alternative

the only case I see it's still useful, is with events and sender param:
if no singleton instance, we have to use null as sender or to declare
specific event handler types

did I missed something ?

--
*/Teträm/*
http://www.tetram.org

"Entre le cerveau et la main, le médiateur doit être le coeur" - Fritz
Lang

 

[Arne Vajhøj]

i'm implementing a singleton class, and changing non static to static
functions, vars, properties one after another I discover all my
implementation can be done as static in the class so there's no need of
singleton instance to use it.

to extend thinking, I wonder in which cases the singleton pattern is
still useful (in C# at least) as, AFAIK, everything we declare in a
class to be instance dependant can be declared static
even constructor and event handlers have their static alternative

the only case I see it's still useful, is with events and sender param:
if no singleton instance, we have to use null as sender or to declare
specific event handler types

did I missed something ?

The singleton pattern is a rather controversial topic
among (OOP) developers.

I would say that the classic pattern's main advantage over
all static are:
* the ability to extend another class or inherit an interface
* lazy loading is more elegant implemented

Arne

 

[jehugaleahsa]

The singleton pattern is a rather controversial topic
among (OOP) developers.

I would say that the classic pattern's main advantage over
all static are:
* the ability to extend another class or inherit an interface
* lazy loading is more elegant implemented

Arne- Hide quoted text -

- Show quoted text -

I had a short discussion with Martin Fowler about extending Singletons
(specifically Registry) to allow for providing production and test
versions of a Singleton. I am not a fan of extending Singletons in
this way. Mr. Fowler made it sound like he prefers all static methods
working on an underlying instance. I share his sense of aesthetics.

However, I am not saying that you should use static variables.
Personally, I think there are still some minor advantages to keeping
an instance in there somewhere. First of all, it can make thread
safety easier. By creating a property or method for getting the
instance you can wrap a lock around it. Rarely do Singletons need to
be thread-safe and even then they rarely need a fine-grain control
over members. Secondly, instances allows you to quickly make your
Singletons "one-per-thread" Singletons. You can place [ThreadStatic]
above the instance and instantly you get a new Singleton for each
thread. The same thing can be achieved using the Session object in
ASP.

So, it is really up to you. If you are in anyway thinking that someday
the class may need to be thread-safe, I'd recommend keeping an
instance sitting around. Whether your static methods reference and
instance or your static instance references your methods is really
irrelevant (unless you like subclassing for test).

 

[Arne Vajhøj]

I had a short discussion with Martin Fowler about extending Singletons
(specifically Registry) to allow for providing production and test
versions of a Singleton. I am not a fan of extending Singletons in
this way.

There is a big difference between having a singleton extend/implement
something and extending a singleton.

The last option is usually a very painful experience.

Arne

 

[Ben Voigt [C++ MVP]]

Hi,

i'm implementing a singleton class, and changing non static to static
functions, vars, properties one after another I discover all my
implementation can be done as static in the class so there's no need of
singleton instance to use it.

to extend thinking, I wonder in which cases the singleton pattern is still
useful (in C# at least) as, AFAIK, everything we declare in a class to be
instance dependant can be declared static
even constructor and event handlers have their static alternative

the only case I see it's still useful, is with events and sender param: if
no singleton instance, we have to use null as sender or to declare
specific event handler types

did I missed something ?

It's useful to have the static methods delegate behavior to an instance
implementing an interface, so that instance can be replaced with a mock
object for testing.