Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re: Making an Existing Class a Singleton

by salva (Abbot)
on Jan 23, 2008 at 17:46 UTC ( #663842=note: print w/replies, xml ) Need Help??

in reply to Making an Existing Class a Singleton

try Class::SingletonProxy
  • Comment on Re: Making an Existing Class a Singleton

Replies are listed 'Best First'.
Re^2: Making an Existing Class a Singleton
by exussum0 (Vicar) on Jan 24, 2008 at 16:13 UTC
    I'd recommend against this CPAN Module for one reason. You have to extend it to make use of it.

    I'd suggest creating a class that has a package scoped variable that you can feed and retrieve single objects. Feed it way of instantiating your object if it isn't created.

    Singleton objects are always a very touchy, delicate things. Containment, testing and what not are difficult.

      I'd recommend against this CPAN Module for one reason. You have to extend it to make use of it.

      And what is the problem with that?

        It's more style issue in regards to OOP. Again, it's style. This is math - if you get the right answer, you probably did the right thing. Advisable is always subjective.

        Let's say for instance, I have a class called Car, and it has attributes like age, color, make, model (with getter and setter methods). Add methods to manipulate the car, like drive, explode, start, stop.

        My first issue is scaling and maintenance. Let's say I have a large number of utility-like things I wish to do. Let's also say I wish to apply them over a large number of classes. I wind up w/ a VERY large amount of code and things that need to be tested. 100 utility things vs 10 classes is 1000 changes in a very naive sense.

        My second issue is, utility methods and interfaces like that have their various places in the minds of OOP purists. Let's say I had other utility methods, like serialization, getting memory foot prints, saving to a db etc. Those aren't properties of the Car per se, but things you do with the language and system.

        It gets quiet awkward when I have a situation like this: If my base interface, called Vehicle had a base of this Singleton, and I extend out Car and Plane off of Vehicle. What if I want one Car, but never need to make a singleton out of Plane. I have this method that'll croak/carp if it's used, but I can't get rid of it.

        It's nicer to separate those utilities out. Have them inspect or act upon my classes or objects in configured ways. For that first issue, it scales nicely. It's now, in my first example, 10 original, maybe (just maybe) untouched classes, and 100 other utility things that inspect those 10. I'll never have stray methods on my second example. I can also write sufficient tests for my utilities and use them on infinite classes and never have to write unit tests connecting the two. Unit tests considered testing local algorithms instead of connected components.

        It's forward thinking on the effects of an entire system, should it be not small, and can be quite huge.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://663842]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (9)
As of 2019-06-19 13:41 GMT
Find Nodes?
    Voting Booth?
    Is there a future for codeless software?

    Results (88 votes). Check out past polls.

    • (Sep 10, 2018 at 22:53 UTC) Welcome new users!