Global in classes

nasty_psycho

I have a question: is globalizing variables inside the functions (using global keyword) of a class a bad habit? if yes, why ?

I'm asking this question because I've heard alot about them...
thank you

sneakyimp

I'm not certain but I would imagin that it depends. The main reasons to use classes are to encapsulate code that might be specific to a particular platform or technology and to hide the details of an operation so tha top-level code is simpler and more readable. Generally speaking, a well-constructed glass is a self-contained, modular piece of code that is independent of other pieces of code.

If you refer to globals within your classes, this can reduce the independence of your class.

On the other hand, if you use the class to define variables in the global scope so that your top-level code can take advantage of it, that might be a useful thing.

nasty_psycho

ok, thanks, I'm asking here because i've asked this question in the polish forum forum.php.pl
and there I've got about 25 replays that they are a bad habbit and shouldn't be used, and that they are used only by beginners...
What do you think ?

halojoy

nasty_psycho wrote:
ok, thanks, I'm asking here because i've asked this question in the polish forum forum.php.pl
and there I've got about 25 replays that they are a bad habbit and shouldn't be used, and that they are used only by beginners...
What do you think ?

I have seen the use of 'global' is class functions.
And as been said, these are mainly scripts that deals with global variables.

Best way is to submit variables as parameters to class function:

$result = $obj->funcname( $var1, var2, var3, var4 );

Or you can have classvariables, that you first set to values,
that are used by class function:

$obj->var1 = xxxx;
$obj->var2 = yyyy;
$obj->var3 = zzzz;
$result = $obj->funcname();

bogu

nasty_psycho wrote:
and there I've got about 25 replays that they are a bad habbit and shouldn't be used, and that they are used only by beginners...
What do you think ?

They were right ...

sneakyimp

In recent work, I stumbled across a case where it seems to make sense to refer to a global variable.

for instance, my session code needs to refer to both the global database object and also the global error handling object.

jdorsch

Don't use globals, the guys on the polish forum were right. There is never a situation where you can't code around them them and they just create dependecy issues and break encapsulation. Also, since a global variable can be overwritten, it can sometimes be a trainwreck if you are modifiying a global variable all over the place and are trying to track it down, or if someone else edits your code and you have a global called $db hidden somewhere and they have no idea where its instantiated or what.

If you need to use a global object, make it a singleton class accessible by a static accessor method. If you are using application wide values such as logins and such, use a constant not a variable.

sneakyimp

so how do you refer to your database class in your session class?

jdorsch

sneakyimp wrote:
so how do you refer to your database class in your session class?

You should use a singleton class

$stmt = db::getDB()->query( $sql ) ;

A singleton is coded like



class db
{
  protected static $db = null ;

  private function __construct() {..stuff..}

  static public function getDB()
  {
     if( self::$db === null )
     {
         self::$db = new db() ;
     }
     return self::$db ;
  }
}

A singleton assures that only one instance of an object is created and that object is reused. Since the constructor is private only the class itself can make an instance of itself, you can't call $db = new db() outside of the class. Also, getDB() creates the instance the first time its called using lazy instantiation, this makes it so you don't have to instantiate utility classes when your script is started, the classes are instantiated only when they are first used.

ahundiak

Don't want to start any wars but using singletons as a replacement for globals is also frowned upon. Singletons are intended to be used when you really want to make sure that only one instance of a class is ever created. In the case of a db connector you might in fact want to access two or more databases within one script.

What you really want is a registry object which in turn holds other objects such as the db connector, logger, session etc. You typically pass the registry along to an object via when the object is constructed. Or possible implement the registry as a singleton.

This article does a better job of explaining then I can.
http://www.phpit.net/article/using-globals-php/

jazz_snob

ahundiak wrote:
Don't want to start any wars but using singletons as a replacement for globals is also frowned upon.

I'll second that.

If you need a "global" in your class, make it an instance var for the class set either in constructor (preferably) or w/ some setter method. Beware that to get desired functionality you sometimes need to pass in the "global" thingy by reference (depending on what type of thingy it is).

Sometimes a defined constant can be a good way out too, since they are always "global".

jdorsch

ahundiak wrote:
Don't want to start any wars but using singletons as a replacement for globals is also frowned upon. Singletons are intended to be used when you really want to make sure that only one instance of a class is ever created. In the case of a db connector you might in fact want to access two or more databases within one script.

What you really want is a registry object which in turn holds other objects such as the db connector, logger, session etc. You typically pass the registry along to an object via when the object is constructed. Or possible implement the registry as a singleton.

This article does a better job of explaining then I can.
http://www.phpit.net/article/using-globals-php/

I suggested a singleton because generally you don't want more than one database access class, session class, or probably an error handling class floating around. Since the singleton is static there is nothing wrong with using it as a global. But you are correct, for other objects that might need more than one instance a registry or mediator is a good solution as specified in your link.

sneakyimp

EDIT: what the heck is a registry (in terms of php code?)

those posts are helpful ('don't use a singleton') but i stiil have no idea how to properly structure my classes.

generally speaking, it is my hope that

a) when i create my database class, error functions are handled by my error handling routine. i have dutifully used set_error_handler() but rather than using trigger_error, i want to be able to pass different parameters so i created an error handling object. i'm thinking maybe i can use the scope resolution operator rather than instantiating my error class? but then where do i put the code to call set_error_handler()?

b) when i create my session handling class, i want any database references to go through my database class and any errors to be handled to be handled by my error handling class. seems like using the scope resolution operator might also be a way to do this but i just don't know.

ahundiak

sneakyimp wrote:
EDIT: what the heck is a registry (in terms of php code?)

This article does a better job of explaining then I can.
http://www.phpit.net/article/using-globals-php/

sneakyimp

Thanks for that article. I will probably start using those techniques.

However, I'm not sure that it solves the questions I was asking. It will make my session and database classes have to refer to yet another class (the registry class). If the plan is to reduce the dependence of my classes on other pieces of code, it would appear that we have accomplished just the opposite.

On the other hand, I can see that instead of referring to several different objects ($db, $error_handler, and $session_handler) then my subroutines and classes can just refer to $registry.

But on the third hand, what if necessary items are not defined in the registry?

still trying to get my head around this...