[Catalyst] Re: using Plugin::Singleton and testing

[A. Pagaltzis]

* Daniel McBrearty <danielmcbrearty at gmail.com> [2006-11-18 02:20]:
> You generally design systems with initial constraints in mind.

Agreed. But it’s a bad idea to design it to explicitly prevent
loosening those constraints, and that’s exactly what singletons
are about.

> You might very well design an application with the idea that
> there is one control surface (keyboard), one (visual) monitor
> and one set of speakers which will receive one signal. It would
> really not be uncommon in some apps to take this view, the cost
> of hardware being what it is.

My laptop has a trackpoint *and* a trackpad, and frequently a USB
mouse connected to it; I use all three devices concurrently.

> And I don't see why a singleton is not a proper object; it
> hides it's implementation from the outside, encapsulates data
> and code, presents an API which can be used to control or
> restrict the way it is used, and so on.

(Just as an aside, I am not arguing that.)

> The fact that the number of instances is limited is neither
> here nor there. Are there no real world classes of objects of
> which there are only one instance?

Why do you have to *prevent* the construction of more than one
such object? Why does it not suffice to trust the API client to
not construct more than the single instance they need?

> The point is not that the idea may be open to abuse - all tools
> are. (We've all seen OO systems that are terrible just because
> of clueless design.) The point is not throwing out the baby
> with bathwater. There is a world of difference between
> "singleton open to misuse" and "singleton considered a bad
> idea". I don't see one argument in that article that is
> powerful enough to wish to throw the tool away.

Singletons are generally a bad idea because you are writing extra
code for the sole purpose of preventing use cases that are almost
never  a) harmful  b) actually impossible.

> In some ways the argument is similar to the arguments often
> given against perl by those that dislike it ("funny syntax" ...
> "encourages poor code" ... ) when those that know better know
> that the bad code comes out of the coder, not the language.

Singletons tie you into an app design even tighter than global
variables can. That may not always be a bad idea, but I would
think it is something you would only use in extremely rare cases.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>