Beefy Boxes and Bandwidth Generously Provided by pair Networks Bob
Problems? Is your data what you think it is?
 
PerlMonks  

Re^4: Making an Existing Class a Singleton

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


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

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.


Comment on Re^4: Making an Existing Class a Singleton
Re^5: Making an Existing Class a Singleton
by salva (Monsignor) on Jan 24, 2008 at 21:57 UTC
    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.
Re^5: Making an Existing Class a Singleton
by yoda54 (Monk) on Mar 18, 2010 at 08:39 UTC
    Great read!! Thanks

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (7)
As of 2014-04-24 10:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (565 votes), past polls