Messaging between objects
Moderator: General Moderators
-
chadjohnson
- Forum Newbie
- Posts: 6
- Joined: Wed Jan 23, 2008 2:54 pm
Messaging between objects
Suppose we're using an object-oriented framework for our web site. We're obviously going to have a few common objects used throughout the framework, such as User and DB (or just a DB connection link). How would you go about making these objects available inside of the member functions of your classes? Would you encapsulate them some common object, like "Settings" or "Context"? Would you make these objects available inside member functions via "global $VARIABLE_NAME;"? Pass them individually or the Settings/Context object as a whole as a constructor parameter for every object in your framework?
Surely someone else has faced this problem before...
Surely someone else has faced this problem before...
Re: Messaging between objects
Most commonly known as a Registry.
In my MVC I pass the Registry to every Controller / Module that is loaded.
In my MVC I pass the Registry to every Controller / Module that is loaded.
-
chadjohnson
- Forum Newbie
- Posts: 6
- Joined: Wed Jan 23, 2008 2:54 pm
Re: Messaging between objects
Wow, dude, you are the man. I think the Registry pattern may be -the perfect- solution. Very cool how it uses the Singleton pattern to ensure the single instance of the Registry is always used, and also VERY cool that you can access this object anywhere by simply calling Registry::getInstance()--without passing any parameters to functions, and without using "global $REGISTRY;".
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Messaging between objects
Although it can be better to inject the Registry object rather than scattering static calls throughout your code -- it is more modular and better particularly for testing. Controller architectures can help with this.
(#10850)
-
chadjohnson
- Forum Newbie
- Posts: 6
- Joined: Wed Jan 23, 2008 2:54 pm
Re: Messaging between objects
What do you mean by "inject"--member variable + constructor variable?
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Re: Messaging between objects
This may seem like a stupid question, but how is a registry any different from a global array like $_SESSION ? It seems like just an object version of an assoc array to me.
I mean I *guess* you can limit the availability of the object, but that seems a bit weak.
Maybe I just don't get it
I mean I *guess* you can limit the availability of the object, but that seems a bit weak.
Maybe I just don't get it
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Messaging between objects
You are right ... the PHP superglobals are a lot like Singleton Registry. And this gets back to the various issues with globals.
There are some differences though. Like that you can make a Registry read-only or write-once. You can also enforce type to only allow objects to be stored. You can set whether they are persisted or not. Etc., etc., etc. So there are a number of things that arrays can't do that you can do with a Registry.
The point of most of them is to limit side-effects. Limiting availability is not "a little weak" ... it is one of the pillars that modern programming practice is built upon.
There are some differences though. Like that you can make a Registry read-only or write-once. You can also enforce type to only allow objects to be stored. You can set whether they are persisted or not. Etc., etc., etc. So there are a number of things that arrays can't do that you can do with a Registry.
The point of most of them is to limit side-effects. Limiting availability is not "a little weak" ... it is one of the pillars that modern programming practice is built upon.
(#10850)
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Re: Messaging between objects
I guess I meant the "weak" comment in light of two things: PHP has yet to support closures, and also if people are integrating your code security is sort of moot.
If it's just conflicts you're worried about I'd make the properties internal to & accessible through the object itself as a public interface, rather than create a separate registry object.
I'm forced to wonder if there's something major I'm missing here... there probably is
If it's just conflicts you're worried about I'd make the properties internal to & accessible through the object itself as a public interface, rather than create a separate registry object.
I'm forced to wonder if there's something major I'm missing here... there probably is
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Messaging between objects
Not sure how closures have anything to do with this. The read-only and write-once qualities are the kinds of things that are essential when people are integrating your code.Kieran Huggins wrote:I guess I meant the "weak" comment in light of two things: PHP has yet to support closures, and also if people are integrating your code security is sort of moot.
I am not sure what you mean by conflicts? Side-effects are most often from visibility beyond a module.Kieran Huggins wrote:If it's just conflicts you're worried about I'd make the properties internal to & accessible through the object itself as a public interface, rather than create a separate registry object.
(#10850)
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Re: Messaging between objects
Closures limit the variable scope of a block, hence protecting your variables from naming conflicts. It seems to make less sense to me now, but it's almost 3am here. Maybe I'll have a better argument in the morning
Probably not.
Objects protect your scope as well, with the added bonus of giving you the tools to control/limit their interface. Between public, private and static variables, methods & getters/setters, I just don't see why you'd ever need a separate object to hold data. Isn't one of the goals of OOP to keep objects and their properties bound in a logical way?
I think maybe I'm just lacking a proper example... I seem to just "not get it".
Objects protect your scope as well, with the added bonus of giving you the tools to control/limit their interface. Between public, private and static variables, methods & getters/setters, I just don't see why you'd ever need a separate object to hold data. Isn't one of the goals of OOP to keep objects and their properties bound in a logical way?
I think maybe I'm just lacking a proper example... I seem to just "not get it".
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Re: Messaging between objects
You have to see the problem a Registry solves before you can understand it. If you take the average MVC approach to web apps, controllers use a slew of objects which somehow need to be accessible from the controller. In PHP the typical approach is a Registry - register the objects before calling the controller, then let the controller pull them out for use.
The other side of the problem is how to allow the controller access to the Registry (this isn't a singleton or global just yet!). The next typical solution is to use a Singleton/Static Registry - which is of course the style exhibiting global behaviour. I hate this approach since a) it's effectively global so any other part of the application can mess with it, b) it can't be easily tested, and c) it's in my opinion a code smell of something gone bad.
The alternate solution to remove the global smell is to inject the Registry into the Controller through the constructor or a setter.
There is still a tiny problem - in a sufficiently complex MVC system (read: Zend Framework) passing a Registry into all controllers may return to haunt you. The problem is that objects are now created outside the controllers, often in some central location, where specific configuration of objects gets difficult to control and manage. In using the ZF I've started migrating towards a Dependency Solution like pico or phemto - or pretty soon possibly Zend_Di. This is an alternative to a Registry which basically replaces the Registry with an object factory which creates objects based on a configuration file. It goes a bit further - allowing me to configure what object dependencies to create at the same time, how to inject those into the parent object etc. It's an added complexity, but I'm a big fan of "thin controllers" so it keeps my action methods lean.
The other side of the problem is how to allow the controller access to the Registry (this isn't a singleton or global just yet!). The next typical solution is to use a Singleton/Static Registry - which is of course the style exhibiting global behaviour. I hate this approach since a) it's effectively global so any other part of the application can mess with it, b) it can't be easily tested, and c) it's in my opinion a code smell of something gone bad.
The alternate solution to remove the global smell is to inject the Registry into the Controller through the constructor or a setter.
There is still a tiny problem - in a sufficiently complex MVC system (read: Zend Framework) passing a Registry into all controllers may return to haunt you. The problem is that objects are now created outside the controllers, often in some central location, where specific configuration of objects gets difficult to control and manage. In using the ZF I've started migrating towards a Dependency Solution like pico or phemto - or pretty soon possibly Zend_Di. This is an alternative to a Registry which basically replaces the Registry with an object factory which creates objects based on a configuration file. It goes a bit further - allowing me to configure what object dependencies to create at the same time, how to inject those into the parent object etc. It's an added complexity, but I'm a big fan of "thin controllers" so it keeps my action methods lean.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Messaging between objects
Yes ... the question becomes: at what level of complexity does the overhead of DI win out over the registry passing? There is no total answer usually. I find I use DI in areas of the application where the number of objects and complexity have exploded, yet keep using an injected registry for the rest.
(#10850)
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Re: Messaging between objects
In an MVC framework, couldn't you just attach the registry to the base controller class?
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Messaging between objects
If you have hierarchy in your controllers, sure...although I would suggest trying to stay away from inheritence...Kieran Huggins wrote:In an MVC framework, couldn't you just attach the registry to the base controller class?
If you care not to use a singleton to access your registry, why not just inject the registry object directly into your controller?
Have a function like:
setRegistryObject() inside your front controller. Add a accessor like getRegistryObject(). When your front controller creates/instantiates the action controller object, inject the registry object or the entire front object.
Now you could access your registry like:
Code: Select all
$this->front->getRegistryObject()Code: Select all
$this->registry;