the wise use of singleton

[phl]

hello,

My project in a web project. I choose to use singleton in one of my
projects. Towards the end I realise that I seemed to have refered to
the fields singleton in my other classes in my business logic a little
precariously. I access my the fields in the singlton in my BLL classes
directly. Is this a really bad violation of OOP rules? It's almost liek
I have use the singlton as one big global variable. Is there any decent
way of using singltons, how do most people use them?

Why I choose singleton to represent some of my data is that, I need to
have say a class that represent user information, that other classes
can access, without having to instaniate a user info class everytime(as
this is a web app in .net, users settings die every post back if you
don't explicitly hold it in memory. I know I could have a base class
with userinfo instead but it would have to be instaniated everytime or
have userobject held in a session variable some where). Using singltons
reminds me of programming in the old days (liek C) where you pass whole
structures to functions, except singltons are lot easier.

So Have I completely abuse the singlton, should I have at least pass
the values of the singlton as my class constructor parameters, instead
of accessing them directly? is there a better way of doing this?
Cheers

 

[Andrew McDonagh]

hello,

My project in a web project. I choose to use singleton in one of my
projects. Towards the end I realise that I seemed to have refered to
the fields singleton in my other classes in my business logic a little
precariously. I access my the fields in the singlton in my BLL classes
directly. Is this a really bad violation of OOP rules? It's almost liek
I have use the singlton as one big global variable. Is there any decent
way of using singltons, how do most people use them?

Why I choose singleton to represent some of my data is that, I need to
have say a class that represent user information, that other classes
can access, without having to instaniate a user info class everytime(as
this is a web app in .net, users settings die every post back if you
don't explicitly hold it in memory. I know I could have a base class
with userinfo instead but it would have to be instaniated everytime or
have userobject held in a session variable some where). Using singltons
reminds me of programming in the old days (liek C) where you pass whole
structures to functions, except singltons are lot easier.

So Have I completely abuse the singlton, should I have at least pass
the values of the singlton as my class constructor parameters, instead
of accessing them directly? is there a better way of doing this?
Cheers

Most of the oppinons on how you have used your single, have been
discussed in the 'Singletons' thread within this NG.

 

[Bruce Wood]

There are two issues here.

First, should you access fields directly, rather than using properties.
In the .NET world, the answer is "no". You should always wrap your
fields in get/set properties. You can read about why in other threads
in this newsgroup, and on MSDN.

Second, should you use a singleton as a space in which to store global
information, or some other construct? The answer is that you probably
want a singleton. The only alternative I know of is to use a static
class (not a base class as you mentioned), but using a static class
introduces some restrictions: you can never pass the class as an
argument, among other things. Singletons create the equivalent of
static classes that can be treated like normal objects, which all
really depends upon whether you will ever need to treat them like
normal objects. In your case, for storing user information, a static
class might have done just as well, but there's nothing wrong with
using a singleton.

Yes, it does look like good ol' C, but then don't be swept up in the
"everything must be an object" frenzy that new converts to OOP so
frequently contract. There are some things in the OOP world that simply
don't need to be objects.

 

[Hans Kesting]

hello,

My project in a web project. [snip]

Why I choose singleton to represent some of my data is that, I need to
have say a class that represent user information ...

[snip]

Is this "user information" specific for the user actually accessing
the site or global to all users?
If various users should have their own version of this "user info"
then a singleton is the wrong choice! A web application is a single
application (having just a single singleton) that can be accessed
by multiple users at the same time.

If that information applies to all users, then you can use a singleton.

 

[Adie]

hello,

My project in a web project. I choose to use singleton in one of my
projects. Towards the end I realise that I seemed to have refered to
the fields singleton in my other classes in my business logic a little
precariously. I access my the fields in the singlton in my BLL classes
directly. Is this a really bad violation of OOP rules? It's almost liek
I have use the singlton as one big global variable. Is there any decent
way of using singltons, how do most people use them?

Why I choose singleton to represent some of my data is that, I need to
have say a class that represent user information, that other classes
can access, without having to instaniate a user info class everytime(as
this is a web app in .net, users settings die every post back if you
don't explicitly hold it in memory. I know I could have a base class
with userinfo instead but it would have to be instaniated everytime or
have userobject held in a session variable some where). Using singltons
reminds me of programming in the old days (liek C) where you pass whole
structures to functions, except singltons are lot easier.

So Have I completely abuse the singlton, should I have at least pass
the values of the singlton as my class constructor parameters, instead
of accessing them directly? is there a better way of doing this?
Cheers

Hi, Microsoft offer several techniques in which to maintain state in an
ASP.NET application, here:
http://msdn.microsoft.com/msdnmag/issues/03/04/ASPNETUserState/default.aspx

The cache object is quite handy when used with the callback mechanism to
refresh it.

 

[phl]

The user information is specific to each user only. My singleton lasts
for the duration of a particular user session. Can you explain why it's
wrong choice and if so what could I have done to make it better? Should
I have instead created a class which deals with saving a user
information object to the session object instead?

 

[H. S. Lahman]

Responding to Phl...

My project in a web project. I choose to use singleton in one of my
projects. Towards the end I realise that I seemed to have refered to
the fields singleton in my other classes in my business logic a little
precariously. I access my the fields in the singlton in my BLL classes
directly. Is this a really bad violation of OOP rules? It's almost liek
I have use the singlton as one big global variable. Is there any decent
way of using singltons, how do most people use them?

There are two quite orthogonal issues here: whether to use a Singleton
design pattern and how knowledge is accessed during collaborations.

Use a Singleton pattern when both of the following conditions are true
in the particular problem solution context:

(1) There should never be more than one instance of the class.

(2) An instance can be created in multiple contexts (by different
objects) or the instantiation logic can be invoked multiple times.

IOW, if the normal instantiation of solution objects precludes the
possibility of creating more than one instance, then you don't need to
control instantiation via a Singleton. However, if both conditions are
true than Singleton is one of the cleaner and more generally understood
mechanisms for ensuring only one instance at a time exists.

The Singleton object may have a need to access information in other
objects. Being a Singleton does not affect that. IOW, collaboration is
exactly the same whether there are no other instances or there are a
thousand other instances.

Note that Singleton is about instantiating objects while accessing
information is about collaboration among objects that are already
instantiated. In the OO paradigm one employs relationship navigation
for accessing knowledge or sending behavior messages. During
collaboration there is an implicit assumption that one gets to the right
object via the relationship path. IOW, it is up to whoever instantiates
the relationships in the path to make sure the right objects are
communicating.

Usually (though not always in dynamic situations where relationships may
be conditional) instantiating relationships is the responsibility of
whoever creates one of the participating instances. Thus whoever
creates the Singleton's object will usually be responsible for
instantiating relationships between it an other objects.

[Note that the instance() behavior in Singleton just creates the
instance. The instance itself should have relationships to other
objects once it is created. Those relationships are navigated for
collaboration rather than invoking the static instance() method. Using
the instance() method to access the instance during collaboration is a
very bad practice because it bypasses all the safeguards inherent in the
business rules and policies that limit which particular instances should
be collaborating. That abuse is, indeed, akin to the unlimited accesses
to global variables in the procedural days.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
(e-mail address removed)
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

 

[Michael Feathers]

Use a Singleton pattern when both of the following conditions are true
in the particular problem solution context:

(1) There should never be more than one instance of the class.

(2) An instance can be created in multiple contexts (by different
objects) or the instantiation logic can be invoked multiple times.

Here's another solution (tongue in cheek):

Use a singleton when the cost of creating another instance is higher than
the cost of replacing someone who's been told not to.