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
hs*@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr):
http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH