[RESOLVED] Question regarding Singleton design pattern

nrg_alpha

I am studying design patterns.. when dealing with the singleton pattern, my understanding is to allow instantiation of this class once (and only once), resulting in a single object based off of that pattern. I did a test to see if I can in fact create more than one object off of this pattern, and seems so (sort of)...

for example:

final class Singleton{
    private static $_instance;
    public $var01, $var02;

// lock constructor and clone magic methods
private function __construct(){}
private function __clone(){}

public static function getInstance($a, $b){
if(!self::$_instance){
    self::$_instance = new self();
    self::$_instance->var01 = $a;
    self::$_instance->var02 = $b;
}
return self::$_instance;
}
}

$testObj = Singleton::getInstance(1, 6);
echo "$testObj->var01, $testObj->var02<br />\n";

$testOBJ2 = Singleton::getInstance(4, 5);
echo "$testOBJ2->var01, $testOBJ2->var02<br />\n";

echo (is_object($testOBJ2))? 'Yep, $testOBJ2 is an object!' . "<br />\n": 'Nope, $testOBJ2 is NOT an object!' . "<br />\n";

echo var_dump($testObj) . "<br />\n";
var_dump($testOBJ2);

Output:

1, 6
1, 6
Yep, $testOBJ2 is an object!
object(Singleton)#1 (2) { ["var01"]=> int(1) ["var02"]=> int(6) } 
object(Singleton)#1 (2) { ["var01"]=> int(1) ["var02"]=> int(6) }

So I can see from the results that in fact the first set of digits (1 and 6) is the only set (as echoing the second set from $testOBJ2 (4 and 5) only shows up as the first set).

What I am confused by is that object $testOBJ2 is in fact an object. My understanding was that once the Singleton class is instantiated, if there is a re-attemp at this, the class would simply return the object instead...

perhaps I'm misunderstanding something here... have I set things up correctly?

NogDog

Both $testObj and $testOBJ2 are references to the same object -- the one that was initially created by the first call to the getInstance() method (with the values of 1 and 6).

After they are both defined, if you were to change those values in some manner via either object variable, the changes would show up for the other one, too.

NogDog

PS: It's probably a good time to recommend some additional reading: http://www.google.com/search?q=why+singletons+are+evil. (I'm not saying to never use singletons, just to consider the pros and cons before getting too attached to them.)

nrg_alpha

Thanks for the explanation, Nog... I guess my understanding was off (as how I understood it was there could be no other object based off of that class [and as a result, referencing wasn't possible, therefore not an issue]).

Or stated another way, I figured that once the Singleton class was instantiated, if I created another object off of it and checked to see if that object existed, I would get some kind of undefined error. Once I saw that echo'ing the values of the second object turned up as the first, I still wasn't thinking in the sense of referencing that original object..

So I guess this truly does mean only one object (rather, the original object's values) is being considered.

Thanks again. I'm still shaky on OOP patterns... I'll get there, one object at a time 😉

nrg_alpha

Heh.. thanks for the google link.. I'll have to read up on it.. regardless to whether they are 'evil' or not, I'm slowly but surely going through patterns..I think the Singleton is used in some of the other design pattens in some capacity (I think).. I don't have any pattern books.. can't afford them at the moment.. so since I like bookstores, it's frequent trips to the store to read up a bit here and there on either GoF Design Patterns or Heads Up Design Patterns (Java based, but the principals hold up).

Weedpacket

Well, you said it yourself: no other object [instantiated from] that class: instead you get the same object from the getInstance() method every time. Like it says in the code:

    // Keep a reference to The One True Instance of the object.
    private static $_instance;
    public static function getInstance($a, $b){
    // Has the One True Instance already been created?
    // If it has, we'll already have a reference to it
    if(!self::$_instance){
        // No: create it.
        self::$_instance = new self();
        self::$_instance->var01 = $a;
        self::$_instance->var02 = $b;
        // The One True Instance has now been created.
    }
    // The One True Instance has been created: return a reference to it.
    return self::$_instance;
    }

nrg_alpha

Yeah, my understanding was skewed.. It boils down to me thinking that internally within PHP, any additional objects would be rejected outright. It's all a matter of referencing it turns out.

Your last comment further cements this understanding:

// The One True Instance has been created: return a reference to it.
    return self::$_instance;

keyword, reference. Now I know. For whatever reason, I wasn't think along those lines initially. Live and learn... live and learn.

Weedpacket

You've already got the "what", I'm just offering a couple of additional viewpoints as to the "why". Doesn't hurt to look at it from another couple of angles.

If you like you can think about how a compiler for a language like Java or C++ or C# operates. (This is for statically-typed languages, not dynamically-typed languages like PHP, but the behaviour from the language-user's perspective is the same). The compiler needs to allocate memory for each entity created (of course), so it needs to work out how big the object will be.

For primitive properties it's easy enough: bytes are one byte, integers are four bytes, and so on. Add those up and you get the total size of the object, right? But what if one of those properties is itself an object? Recurse and add the calculated size of the property? But what if the object can contain an instance of its own class? Infinite recursion?

Instead, for non-primitive properties, what is actually stored in the object is the memory address of where the property's value is to be found. And a memory address is a primitive type (four bytes on a 32-bit processor, eight bytes on a 64-bit processor), so it can be stored directly and the total size of the object can be calculated and allocated.

Different languages hide this to different degrees. C doesn't hide it at all (and gets much of its power from the fact), C++ would like to hide it but it's C underpinnings won't let it. Java hides it thoroughly, while C# lets you mess with it so long as you explicitly state that what you're doing is "unsafe" (with the .NET framework providing classes that encapsulate most of the reasons you'd want to).

The difference between those languages and PHP is that in those languages variables have types, while in PHP the type belongs to the value stored in the variable. But reference is still the key word.

Consider a doubly-linked list structure, where every element is an object that has a $next field (which is null for the last element in the list) and a $previous field (which is null for the first element in the list). The fields work like you'd expect: $foo->next is the next element after $foo and $bar->previous is the previous element before $bar. But this can only be achieved if objects are stored and passed around as references - because if $foo->next really did contain the next object (instead of just a reference) $bar->previous really did contain the previous object, then $foo->next->previous would blow up in your face.

nrg_alpha

Thanks for the explanation, Weedpacket.

While I'm not familar with compilers nor their mechanics (I don't use languages such as Java, C++, C# - not yet anyway - been toying lately with the idea of learning either Java or C++), I'll drink this in and digest what I can.