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

Re^2: Making an Existing Class a Singleton

by exussum0 (Vicar)
on Jan 24, 2008 at 16:13 UTC ( #664060=note: print w/replies, xml ) Need Help??

in reply to Re: Making an Existing Class a Singleton
in thread Making an Existing Class a Singleton

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.

  • Comment on Re^2: Making an Existing Class a Singleton

Replies are listed 'Best First'.
Re^3: Making an Existing Class a Singleton
by salva (Canon) on Jan 24, 2008 at 16:24 UTC
    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.

        oh, I see, Class::SingletonProxy doesn't work that way, you don't have to use it as the base for your classes.

        Suppose you already have a Car class...

        package Car; our @ISA = qw(Vehicle); # nothing related to Class::SingletonProxy goes here! sub wheels { 4 }
        ... and so you want to create a singleton for it:
        package MyCar; use base 'Class::SingletonProxy'; sub SINGLETON { Car->new('Ferrary', 'F40', 'red') }
        and then you can access the singleton from your scripts as...
        MyCar->go_supermarket(speed => 200);
        Notice that the Car class remains untouched!
        Great read!! Thanks

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (2)
As of 2023-04-02 03:34 GMT
Find Nodes?
    Voting Booth?

    No recent polls found