Can use of singletons denote poor project design?

[John Fly]

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.

Thank you,
JF

[John Fly]

I believe some of the contentious points here have come about because
of the reason posted earlier by gottlobfr...@gm ail.com

I doubt you are lazy, (in fact it sounds like your are making extra
effort to use OOP, code separation, etc) but I point out how that
sentence sounds, as something to reflect upon. In fact, if I didn't
think you cared, I wouldn't bother pointing it out.
After reading all the replies and links I seem to fit all the proper
uses of singletons as described(mostl y), but I feel I didn't put that
information out very well.

I do have one question for Philip:To achieve the moral high-ground here, you might admit that most modules do
not write on your Singletons (do not set their Set() methods). Global
constants are harmless, therefor global defacto-constants inside Singletons
are mostly harmless.

Forgive me if I mis-understand, right now the opposite is true, evey
module does or can call "set" methods on the singleton(s).

reflecting on the comment on multithreading from dietmar and Philip's
comments have made me realize that I need to go back and refactor much
of the information I was keeping in the "program state" part of the
data format class structure. BTW this was already in my head because
no real design time was given, and I've really been the sole developer.
This just gave me the added push I need to get the cogs in my mind
moving properly.

I have some work ahead of me, but I'll be back with a better design and
more questions later.

Thank you all
JF


Hope none of my replies were too terse or sounded arguementative, its
been a long day at the end of an even longer week.

[Phlip]

John Fly wrote:

Forgive me if I mis-understand, right now the opposite is true, evey
module does or can call "set" methods on the singleton(s).
Hmm. Suppose the Foo module Sets a 42 into a Singleton. Then the Bar module
reads it and uses the 42.

Now change the program. Maybe change Frob that calls Foo and Bob that calls
Bar. You don't notice that Bar now runs before Foo.

The program will fail in a mysterious way, at runtime.

If Bar called Foo directly to get the 42, then more kinds of changes to the
code will either work or fail at compile time.
reflecting on the comment on multithreading from dietmar and Philip's
comments have made me realize that I need to go back and refactor much
of the information I was keeping in the "program state" part of the
data format class structure. BTW this was already in my head because
no real design time was given, and I've really been the sole developer.
This just gave me the added push I need to get the cogs in my mind
moving properly.
Please don't say "refactor" without unit tests. That word is spreading a
little too far. I'm aware it appears in the test-free book Design Patterns,
but the book Refactoring has since taken care of that.
I have some work ahead of me, but I'll be back with a better design and
more questions later.

Please put them on news:comp.objec t . The people on this newsgroup who like
only raw sterile C++ syntax questions are getting antsy. And people using
other languages deserve to read these threads.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!