A single(ton) child amongst us...

delayedinsanity · 04-24-2008, 11:31 PM

Okay, here's what I've got so far.

I like to keep things organized, so all my classes are divided into their seperate areas of expertise. I've got a session.class, mail, form, and database class.

I've implemented a singleton design pattern to the best of my ability, so every page does at least a couple specific things at this point. First, it includes the configuration file -- this holds all the site wide constants and variables, as well as another class, called 'ke' for the sake of this post which only has two static function calls. One of those being the singleton loader.

Now what I want to do, is organize even further as I get deeper into the depths of this beast. I want to split the database class up into child classes. Right now it opens the connection on __construct, has basic $object->query() type functions and then all the UAC and session based database calls. What I want is a very stripped down database class that only has the database connection and basic query type methods, and then I'll sort all the UAC methods into another class, all the session database methods into another, and eventually, database methods specific to their cause into their own classes.

Now here's my conundrum. It seems simple enough, add the parent class definition to my config file, which will be included on every page regardless, then load the child classes into memory as I need them and be on my merry way

But if for example, I call uac.database.class and gallery.database.class, and other.database.class on one page, am I not opening three seperate database connections with each call to parent::__construct()? What if I'm calling four other children on one page? 6? 10? I doubt it, but what if?

I'm thinking maybe I can reduce this using the singleton by simplifying my database class down to just the necessary calls, and making fully independent (non-child) classes for the UAC, gallery, et al which just get the database object themselves in each function call... or can I call my database class via __construct and make yet another reference to it?

PHP Code:


			
public function __construct() {
    $this->db =& ke::getInstance('database');
}

public function doSomething() {
    $q = "SELECT name FROM table WHERE this='that'";
    return mysql_query($q, $this->db->connection);
}

I just thought of that right now... seems in my head like it should work. That won't cause any kind of circular program logic will it? Having getInstance() call a class who's construct calls getInstance()? Seems to me like it shouldn't be a problem, but I'm still naive on a few counts.

I think I'll give that a go, and see if the whole yard blows up in the process. Any thoughts though?
-mark

delayedinsanity · 04-25-2008, 11:09 PM

I guess I answered my own question without knowing it. My session class is already calling my database class during construct, I just wasn't assigning it to a local variable reference due to the fact than when I originally wrote the classes, I was using global's to pass my references around.

Hrmm. Time to go through everything again and clean up and document my code some more so I don't do anything else without realizing it.
-m

delayedinsanity · 04-25-2008, 11:54 PM

Wait a minute, what if... I call the database class with an argument,

PHP Code:


			
$this->db =& ke::getInstance('database', 'uac');

...

public function __construct ($szChild=null) {
    if (isset($szChild)) {
        $this->child =& ke::getInstance($szChild);
    }
}

Hmmm, but that may get more messy than useful. All my calls would be via $this->db->child->method(); not that that's too long I guess. But it might be more readable in the end to just call the child database class into $this->db, and have that class call the parent database class itself. Then I could be making all my calls via $this->db->method(); wait no that's retarded. I wouldn't have access to the parent class methods except through the child class, which shouldn't be a problem but why not accommodate for the need before it arises? So then maybe I should actually use OOPs inherent parent/child architecture and include() the parent definition in each child's file, or require_once() it anyways so if I call two childs on one page I don't load the parents file twice.

I think I just confused myself. Ignore everything above there, we'll just call that "rambling".

Is it possible to use dynamic variable names in classes? So if I wanted to call my database class, and then call a child of said class... So if I called uac, $objCurrent->db->uac->method() could be used instead of 'child', or if I called blog, $objCurrent->db->blog->method() without having uac and blog as already defined variables of db? hmmm

delayedinsanity · 04-26-2008, 12:41 AM

This is a pretty one sided discussion so far. Thanks for letting me use your message boards as a big ole online notebook. :)

I think I've figured out what I'm going to do. Right now, getInstance takes one argument, the object to be loaded. If I change it to

getInstance($szObject, $szInclude=null)

Now it'll load the object into memory, but if $szInclude is set, it will load said file into memory before loading the object. So if I load UAC which is a child class of MySQLDB, I'll use

$this->db =& ke::getInstance("uac", "MySQLDB");

and the method will first require_once the MySQLDB file (the parent class), then load UAC (the little'un) into $this->db so that I can call $this->db->childMethod(); or $this->db->parentMethod(); without obfuscating my -> chain any further than needs to be.

PHP is f'n cool.

This may still not be the best way to go about this, but if I come up with anything else, or if anybody has any thoughts...
-m

Tanax · 04-26-2008, 12:47 AM

Haha, sorry, but I just gotta say...
You're funny

delayedinsanity · 04-27-2008, 07:17 AM

If anybody out there cares, I figured out the problem of the "dynamic" variable. Where were you OOP guys on this one?! I know, I know, if the post is longer than two paragraphs, and the poster seems to be talking to himself a little more than usual, you don't read or reply. It's understandable.

If anybody else is curious though, it's really easy to set up dynamically named object variables thanks to the magic functions __set(), __get(), __isset() and __unset().

For example, a really bare bones demonstration;

PHP Code:


			
class isPossible

{

    var $possible;



    public function __construct() {

        $this->possible = ", hells yeah";

    }



}; // possible

        

class dynaSample

{

    private $dynamic = array();



    public function __construct() {

        $this->is = new isPossible();

    }



    public function __set($szName, $szValue) {

        $this->dynamic[$szName] = $szValue;

    }



    public function __get($szName) {

        if (isset($this->dynamic[$szName])) return $this->dynamic[$szName];

    }

    

    public function __isset($szName) {

        return isset($this->dynamic[$szName]);

    }

    

    public function __unset($szName) {

        unset($this->dynamic[$szName]);

    }



}; // dynaSample



$dynamic = new dynaSample();

$dynamic->hope = "this works";



echo $dynamic->hope;

echo $dynamic->is->possible;

Yes, yes, you read it here /first|second|[A-Za-z0-9]+/

The above would output, as one may suspect, and in my case hope,

this works, hells yeah

*dusts off* moving along...
-m

delayedinsanity · 04-27-2008, 04:37 PM

What the hell...

You don't even need to use the magic functions, PHP lets you call into existence any variable you want, at any time.

Something seems a little fishy here...
-m