You generally design systems with initial constraints in mind. 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. It's not about having a number of soundcards - one
soundcard can mix many sources anyhow. In this type of app it would be
about restricting the number of signals that can be heard, and knowing
that you will never have more speakers than you will have
PCs/applications.
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. 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?
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.
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.
On 11/17/06, Nilson Santos Figueiredo Junior <[EMAIL PROTECTED]> wrote:
On 11/17/06, Daniel McBrearty <[EMAIL PROTECTED]> wrote:
> So my original example : say we have an application that streams
> audio, and only one source may be streamed at a time. Having more than
> one player instance in existence could violate this on many OS's. Even
> if the OS would cause an error (due to more the resource being busy
> when it starts up), you just don't want it to happen. How would you
> design this?
Right. But then you are on system with two sound cards and suddenly
you're able to stream two sources at the same time. Suddenly, you'll
find the need for proper objects, since now you'd need one instance
per sound card.
I think this is the point the guy who wrote the linked rant was trying
to get at. People use Singletons due to lack of foresight since,
eventually, they will need to have more than one instance. Of course
this is not always true and you might really only need one instance
ever, but since using Singletons inherently breaks some cases of
reusability and is against fundamental OO theory, it's a practice that
should be avoided.
-Nilson Santos F. Jr.
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
--
Daniel McBrearty
email : danielmcbrearty at gmail.com
www.engoi.com : the multi - language vocab trainer
BTW : 0873928131
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
