PHP5 can a child class be a static singleton?

Roger_Ramjet

I ahve a singleton pdo databasr class that works just fine.

What I was wondering was can that class inherit from a non-static parent?

class myParent {
    static protected $var1;
    protected $var2;

 public function __construct($input1) {
     $this->var1 = $input1;
     }

public function to_inherit() {
    // do something
    return $this->var2;
    }
}

class singletonChild extends myParent {
     private static $instance ;

 private function __construct($input1)
     parent::__construct($input1);
     }

public static function getInstance($input1) {
    if(!isset(self::instance)) {
         self::instance = new singletonChild($input1);
         }
     return self::instance;
   }
}

$test = singletonChild::getInstance($input1);

$result = $test->toInherit();

// which should return $var2 from the parent: or not as the case may be

Any thoughts?

NogDog

I see no reason you cannot do it. Just be aware that the static variable in the parent class can be modified by any instantiation of that class or any other child classes that extend it, so that part of the singleton class will not exactly be "singleton" in its nature.

kakki

i guess, that $instance is static, therefore all attributes of myParent are static as well ...

Roger_Ramjet

NogDog;10880140 wrote:
I see no reason you cannot do it. Just be aware that the static variable in the parent class can be modified by any instantiation of that class or any other child classes that extend it, so that part of the singleton class will not exactly be "singleton" in its nature.

Which is pretty much what I want, or rather what I was pondering on.

In a class hierarchy, can some of the descendent branches terminate in a singleton?

kakki;10880141 wrote:
i guess, that $instance is static, therefore all attributes of myParent are static as well ...

Should be, at least in the singleton instantiation. I was just making sure. I may find that I need or want it to be otherwise though.

What I am thinking on here is a static pdo class that gets it's db vars ($var2) from a parent class that reads a system config file ($input1) from a path outside doc root. Just security: don't leave the db password lying around where people can get at it. The same file reader would also pass system settings (more $var2) to other child class constructors.

I was just wondering if anyone had come across such a pattern before and knew the ins and outs of using it.

Weedpacket

Roger Ramjet wrote:
In a class hierarchy, can some of the descendent branches terminate in a singleton?

I don't see why not: the crucial thing about making a singleton a singleton is what you've done: making its constructor private (so that it can't be instantiated directly) and providing user access to the instance created and maintained by the class itself. There isn't anything in that which gets ruled out by inheritance.

It occurs to me also to point out that in any object-oriented language with a unified type system, singleton classes always extend other classes - all the way back to the common "Object" class.

jazz_snob

Unit testing would uncover any possible gotchas.

A possible consideration would be reuse. You've probably lost the capability to use singletonChild class everywhere you can use the parent class because the parent class has a public constructor.

NogDog

From a theoretical standpoint, it seems wrong to me to have a class extend another class when you can't really say that the child class is a more specific case of the parent class. Rather, it seems more a work-around as a convenient way to avoid using globals or passing objects around.

I'd be more inclined to instantiate the settings class, then pass it as a required parameter to the DB class's constructor (or the getInstance() method in this case -- though there are those who would say using singletons is too much like using globals, too), using type-hinting. This keeps the interface clear and self-documented.

Weedpacket

Mmhm. There are generally three ways to build up a class.

Inheritance; where the new class Foo extends an existing class Bar. This is appropriate when a Foo is a Bar.
Aggregation; where the new class Foo has a Bar as one of its properties. This is appropriate when a Foo has a Bar. (Like NogDog, it sounds to me like this is more what you're after: the PDO class has a configuration...)
Interface implementation; the new class Foo implements the interface Bar. This is appropriate when a Foo acts like a Bar - however it actually does it.

Roger_Ramjet

Hmm, all points taken, and thanks.

I agree with you Weedpacket, with a pdo class it is a case for aggregation.

But what about eg a Form Factory with a genuine class hierarchy, no breach of principles there?