I think you should give objects a try, for more reasons than just avoiding naming collisions. Here’s why.
I think I’m a pretty typical Wordpress user. I learned a lot of my PHP by playing with themes to get them to do things they didn’t by default. So when I decided to write a plugin I pretty much hacked it together using the guidance that was available.
The only real introduction I had to objects when I started writing plugins was a brief piece about avoiding naming collisisons. None of the guidance seemed to offer more than that so I never really gave it much thought.
Typically my plugins were structured something like this:
[php]
//plugin headers
class myClass {
function myFunction() {
//do stuff
}
}
add_action('wp-head',array('myClass','myFunction'));
There isn’t anything wrong with this, but classes can do so much more once they are instantiated as an object. Typically I now structure my plugins more like this:
[php]
class myClass(){
function myClass(){
//php 4 compliant constructor
add_action('wp-head',array(&$this,'myFunction'));
}
function myFunction(){
//do stuff
}
}
if (class_exists('myClass')) {
$myClass = new myClass();
}
So what are the advantages? The real benefits are simply those gained by using object oriented code versus procedural code. The code becomes easier to maintain and easier to reuse the individual functions in other classes.
It can also be useful for abstracting the administrative content away from the actual code you are modifying; for example, I have found it useful to load all of the plugin options using the constructor and keep them in an internal variable for later use by whichever functions happen to need it using something like this:
[php]
class myClass{
function myClass(){
$this->options = get_option('myPluginOptions');
add_filter('the_content',array(&$this,'myFunction'));
}
function myFunction($content){
if ($this->options['wrap-content'] == true) {
return '
';
} else {
return $content;
}
}
}
So, if you are not already instantiating your classes, then I suggest you consider it. You might even enjoy it.
(__)
`
Nice article. I myself also use a objects for my WP plugins. The only difference is that I kickstart them in a more spartan way – just calling something like this:
Class wp_something {
…
}
new wp_something;
because, actually, I only need to run the constructor of the class – I do not need a variable storing the created object ;)
(__)
`
Oops, in all the time I’ve been using WordPress I hadn’t noticed. Thanks John.
(__)
`
Andrew, I know I should be worrying about more pressing issues, but you know it’s WordPress (with a capital P) and not Wordpress don’t you?
That caveat aside, this is a nice little site you’ve got here. I’ll subscribe once you change the title ;-)
Keep up the good work.
(__)
`
Fullo, I did know about the PHP 5 fallback which is why I felt secure in using it; however, it is something that needs to be considered as PHP 6 won’t have it any more.
I guess it really is a case of deciding how long the plugin is likely to be around, and whether you want to support it later in its life to upgrade to PHP 6.
Having said that many hosts are only now getting up to PHP 5. If PHP 6 won’t be backward compatible then I guess you need to wonder how long it will really be until PHP 6 is offered. We could be facing up to 5 years before it becomes well supported.
That’s a long time for a plugin.
(__)
`
as I know call_user_function_array can be used to call statically an object method.
But I don’t know if there are some valid reasons to not use __contruct($args) { $this->myClass($args) ); as you suggest.
Btw, I’ve studied a little more and I’ve discovered that
however, IMHO, this should not be used. Especially if you work with object that extends other object. Because it should be very easy to break your code simply changing the name of the parent class [parent::MyParent ==> parent::NewParentName ].
(__)
`
Thanks Fullo. I did consider doing something like this but my desire to simplify often gets the better of me.
Is there a benefit to using call_user_function over simply calling myClass from within the __construct method?
(__)
`
nice tutorial, but instead of use a php4-only object you should create a php5, or crosscompatible, object.
ie.
class myClass(){
function __construct(){
// do something
}
function myClass($args){
//php 4 compliant fake constructor
$args = func_get_args();
call_user_func_array(array(&$this, ‘__construct’), $args);
}