Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^3: Making an Existing Class a Singleton

by salva (Canon)
on Jan 24, 2008 at 16:24 UTC ( [id://664065]=note: print w/replies, xml ) Need Help??


in reply to Re^2: 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.

And what is the problem with that?

Replies are listed 'Best First'.
Re^4: Making an Existing Class a Singleton
by exussum0 (Vicar) on Jan 24, 2008 at 17:51 UTC
    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!
        Something feels really odd about this, in regards to serialization and any type of inspection one may do. I only speak to working with someone's really wonky code to determine the object's class and tripping up on someone's proxy.
      Great read!! Thanks

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2024-03-29 09:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found