Re: Can use of singletons denote poor project design?

In article <1140883473.012281.39060@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"Ed" <iamfractal@xxxxxxxxxxx> wrote:

Daniel Parker wrote:
Phlip wrote:
[X-posted to comp.object and followups set]

John Fly wrote:

Right now I use [singletons] 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


Regards,
Daniel Parker

To answer the question in the subject: yes.

Further, to rephrase the quesiton as, "Can use of X denote poor project
design?" where X is any design pattern/documentation/metric/etc., the
answer is probably: yes. Anything can be overused/abused.

To focus, however, on Singletons:

"It is a truth universally acknowledged, that a singleton in possession
of complex behaviour, must be in want of a refactoring."

It is true, furthermore, that all singletons in a project can be
replaced by one, less complex singleton: I tend to have only one
signleton in my code, which is a ConcreteRegistry. During start-up, all
the other bits register themselves in the registry, for example the
Model, View, and Controller interfaces. Then they can all access one
another by:

class ConcreteView implements View {

void doSomething() {
Model model = ConcreteRegistry.getInstance().getModel();
}
}

This tends to lead to the result that a lot of the classes depend on
the singleton, but this is not necessarily a bad thing as the
singleton's behaviour is rigourously limited to storing and serving
interfaces, and the singleton itself is not dependent on the methods of
the interfaces that it stores.

The point is: here's a singleton with loads of dependencies on it, yet
this isn't, I think, bad design. So although the answer to the
subject-line question is yes, the converse is not true: using
singletons does not imply bad design.

This is the exact pattern that I *would* consider bad design. The
ConcreteView class above depends on View, Model, and the
ConcreteRegistry. One more class than it needs to depend on. Worse yet,
some other object of possibly another class put the model object into
the registry and our ConcreteView class depends on *it* as well,
whatever it may be. That hidden dependancy is very dangerous IMHO.

This is the exact anti-pattern that Daniel Parker was talking about in
his earlier message where he bemoaned "Bob"
<jVOLf.26216$%14.696722@xxxxxxxxxxxxxxxxxxxxx>



--
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.
.

Relevant Pages

  • Re: Can use of singletons denote poor project design?
    ... Program State: Again a central point to keep track of program status. ... To pass fake data into the modules that use those systems, ... Singleton is "because there's only one of them", ... returns a default date format, which is a singleton object, there is ...
    (comp.object)
  • Re: Can use of singletons denote poor project design?
    ... Daniel Parker wrote: ... Program State: Again a central point to keep track of program status. ... "It is a truth universally acknowledged, that a singleton in possession ... Model, View, and Controller interfaces. ...
    (comp.object)