In article <11**********************@v46g2000cwv.googlegroups .com>,
"John Fly" <Jo*******@msn.com> wrote:
I'm working on a large project(from scratch). The program is
essentially a data file processor, the overall view is this:
A data file is read in, validated and stored in a memory structure
similar to a database or XML representation. Rules to modify the stored
data will be executed, then the data will be transformed into an output
format.
Think something similar to FormatA -> XML -> Manipulate XML -> FormatB
The project is large but so far I have been able to keep it very
modular using OO design. I do however have questions about my use of
singletons for certain aspects of the program.
*
I've found the use of singleton objects quite nice for various aspects
of this program, I do enjoy having the ability to use a singleton class
by using the Class::Instance() syntax, thus removing the need to pass
instances around in all my function calls. Also very useful is the
ability to use a guarenteed single instance by simply including the
header containing my singleton.
Right now I use them for :
Logging server : A central message storage and distribution to N number
of reports/logs)
Program State : Again a central point to keep track of program status.
Central Data representation
I didn't know if the use of multiple singletons could represent a
design flaw and would like some opinions on their use or the use of
multiple singletons in a single project.
I know its vague, but without going into a verbose write-up I don't
know what else might be of value here. If there is a bit of
information I can provide, just ask.
Again I find myself following Phlip, if he wants to dive in face
first... :-)
Yes John, Signletons *can* denote poor project design, but they don't
always do so. I doubt a project would ever be called ill-designed simply
because no singletons existed in it however, so you are right to be
concerned. The real question in *this* case though is, "Do the
singletons in my program denote poor project design?" I don't know the
answer to that question, but I will give you an example of a singleton
that I feel *might* denote poor design and let's see what happens...
At the Microsoft website <http://tinyurl.com/30wa>, is an example of a
singleton used to explain the concept:
For example, when a class is being used to maintain an incremental
counter, the simple counter class needs to keep track of an integer
value that is being used in multiple areas of an application. The
class needs to be able to increment this counter as well as return
the current value. For this situation, the desired class behavior
would be to have exactly one instance of a class that maintains the
integer and nothing more.
Sounds quite harmless doesn't it? A perfect example of a singleton?
The problem comes in when several different modules in our program start
incrementing the counter, reading its current value, and performing
different behaviors based on its value. Module A increments the counter,
Module B detects that the counter is over a certain threshold and does
something as a result. IE module A indirectly caused module B to change
state. A and B are coupled together (A uses B) without there being any
explicit or obvious mechanism, and we can't test this interaction
without bringing both modules and the singleton into the test harness.
Now think about the same problem, but there are 5 or 25 different
modules that all increment that counter, and perform operations based on
its state. That's some nasty coupling there.
You see, a singleton in and of itself isn't "bad design" (even this
counter class,) it all depends on how it's being used. If the state of
the singleton causes other modules to change their behavior, *then* it's
bad design.
In your particular situation, I suspect the logging_server is a fine
example of the singleton pattern, I doubt that there are any modules
that change state or behavior based on the state of the logging_server.
However, I'm not so sure about your Program State singleton. I suspect
that its state *does* affect many different modules in a non-obvious and
non-local way, but I could be wrong, I'm just going by your short
description of the thing and its name.
To Phlip and Daniel Parker... One of you is saying, "sometimes
singletons are bad" the other is saying, "they're not always bad." Let
me say, "your both right." :-)
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
