Page 1 of 1

base class

Posted: Wed Oct 01, 2008 4:37 pm
by koen.h
I know some would like to shoot me based on the title alone :mrgreen:

I've seen frameworks where about every object gets passed an instance of a service locator or registry or something with similar capabilities. This in the name of avoiding globals, which, we all know, are bad. I think passing this introduces a new kind of global object though. And worse, often you can't even be sure what object class you get when you ask this service locator for an object (eg database) other than you happened to read the bootstrap file.

Based on this observation I think it can't be that bad to have a base class having methods that locates a service. Or provides access to a logger object so you can do '$this->log('start_authentication_check')'. What would be against having these two kinds of functionality in a base class as opposed to the situation described above?

Re: base class

Posted: Wed Oct 01, 2008 5:16 pm
by Christopher
koen.h wrote:I know some would like to shoot me based on the title alone :mrgreen:
BANG! ;)
koen.h wrote:I've seen frameworks where about every object gets passed an instance of a service locator or registry or something with similar capabilities. This in the name of avoiding globals, which, we all know, are bad. I think passing this introduces a new kind of global object though. And worse, often you can't even be sure what object class you get when you ask this service locator for an object (eg database) other than you happened to read the bootstrap file.

Based on this observation I think it can't be that bad to have a base class having methods that locates a service. Or provides access to a logger object so you can do '$this->log('start_authentication_check')'. What would be against having these two kinds of functionality in a base class as opposed to the situation described above?
As you can maybe start to see, there is a problem here that has no one good solution. We are all looking for the best implementation for the common objects in our applications. There are trade-offs either way you go. If one direction or the other works for you ... and keeps working for you as the code grows and changes ... then that is a good decision.

The discussion of why you might make one trade-off rather than another depends on your goals, outlook, and the problem at hand. Inheritance, Registry/Locator, and Dependency Injection solve this problem from different directions. It's more involved discussion. ;)

Re: base class

Posted: Wed Oct 01, 2008 5:57 pm
by josh
Further elaborating on the syntax that makes a registry pattern possible, we're specifically using static classes to make classes accessible from within any scope, as long as you prefix your class names properly there will be no name collisions and it is not the same thing as globals, globals have to be declared global, and still live in a specific scope, statically induced methods have variables that exist within their own encapsulated scope. Global namespacing if you will ( your class name is the name of the scope, and you can use generic variable names MyClassA::foo and MyClassB::foo are 2 different variable for example )

There's also registry patterns that build ontop of the singleton pattern, which itself builds ontop of the static concept to ensure only one instance of an object exists, often times your registry will be a singleton