I need your thoughts...

jordie · 09-29-2007, 04:08 AM

I work on an application that uses OOP heavily.

Because the classes are intermingled a lot (I'm trying to reduce this) they are stored in globals like:

PHP Code:


			
$GLOBALS['MY_CLASS_NAME'] = new classname();

However I came across another method that might be 'nicer'. Using static variables in a function. So the code would be like:

PHP Code:


			
function &GetClass($className){

    static $classes = array();

    if(isset($classes[$className])){

        return $classes[$className];

    }else{

        include_once(BASE_PATH .'/includes/classes/class.'.strtolower($className).'.php');

        $callClass = $className;

        $classes[$className] = new $callClass;

        return $classes[$className];

    }

}

Then the code from above would turn into:

PHP Code:


			
$objMyClass = &GetClass('classname');

Though its not global anymore, its in the static variable of the function, so I can still access it from withing another class or function. Example:

PHP Code:


			
function MyOtherFunction($objMyClass){

     $objMyClass = &GetClass('classname');

     echo "My class says this: ".$objMyClass->ReturnSomething();

}

It looks a hell of a lot nicer than:

PHP Code:


			
function MyOtherFunction($objMyClass){

     echo "My class says this: ".$GLOBALS['MY_CLASS_NAME']->ReturnSomething();

}

I know some people might use:

PHP Code:


			
$objMyClass = new myclass();



function MyFunction(){

    global $objMyClass;

    echo "do something ".$objMyClass->DoSomething();  

}

But I can't do that from within another class though can I? Plus I don't like the idea of having those globals all over the place.... I'd rather just use $GLOBALS

But I guess when it comes down to it, I'm going to have to do some speed and memory tests and see which comes out on top. What does everyone else think about this though? Which is the 'better' method? Are there other methods that would be better? (Remember the instantiated classes need to be accessible anywhere)

Karl · 09-30-2007, 12:52 PM

Have you considered using "static classes"? These are great when you know that you do not need to create instances of a class, for example, a Session class.

In OOP however, I tend not to create too many globally declared functions/variables, so I personally don't run into this problem. For example, each "page" can be expressed as a Class. Seeing as each page is a "page", we can wrap all our page related data inside this class, we can then give access to common objects (as properties) inside the Page class.

So let's say I added myFunction() to my LoginPage class, I can simply access common objects though the page's properites, such as $this->m_pMyObject->doSomething();

It's a different pattern to development, and I guess you really can't switch over this late into it? I would seriously suggest the use of static classes over global variables, infact, you should aim to cut down on the number of globally defined variables and functions in your script, this is one of the places where OOP should shine.

jordie · 09-30-2007, 04:56 PM

Quote:

Originally Posted by Karl

Have you considered using "static classes"? These are great when you know that you do not need to create instances of a class, for example, a Session class.

In OOP however, I tend not to create too many globally declared functions/variables, so I personally don't run into this problem. For example, each "page" can be expressed as a Class. Seeing as each page is a "page", we can wrap all our page related data inside this class, we can then give access to common objects (as properties) inside the Page class.

So let's say I added myFunction() to my LoginPage class, I can simply access common objects though the page's properites, such as $this->m_pMyObject->doSomething();

Ah ha yes, but as far as I know that requires PHP 5, yes? Our current minimum requirements are PHP 4.3, and I seriously had to push to get that far. (Previously it was 4.1) I would absolutely love to put our requirements at PHP 5.2, but that would alienate a major portion of our current and potential market, so thats not an available option. :( We really have to wait until a majority of hosts (shared hosts) provide PHP5 by default.

So I'm kind of limited here. I would love to go all php5 on this app (which is a CMS of sorts), but its just not possible. :(

Quote:

Originally Posted by Karl

It's a different pattern to development, and I guess you really can't switch over this late into it? I would seriously suggest the use of static classes over global variables, infact, you should aim to cut down on the number of globally defined variables and functions in your script, this is one of the places where OOP should shine.

Since I've taken over this project a while ago I've been reducing them as much as I can, and reducing the dependencies on each other as much as possible also. I've lowered the memory usage significantly, and I'm thinking if I change to the &GetClass() method I can reduce it even further.

Currently all classes are included, defined and initialized even if they're not needed by that certain page request. This is obviously rather stupid. :( So I'm thinking if I change to the &GetClass() idea each class will only be included, defined and initialized when they are actually needed, while still keeping them global in some respect.

Another pain is the template system which uses a class for each section. For example, A class for PageHeader , a class for "RecentNews", a class for "CategoryMenu". It seems like a bit of overkill, but then these classes also reference the core classes. E.g. the "ViewPage" template class will want to use the core page class, but so will the "PagesMenu" so it know what the current page is. So this means the core class, after being initialized, needs to be globally available as many different template classes may want to reference it.

I'm looking at writing a new template system, which I'd love to get more opinions on, but I'll make a separate post another time as it'll take a little while to explain. But this one wouldn't be so OOP, as I don't think it really needs to be.