Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

In many themes I've seen (including TwentyEleven) and in the examples I've found online, when building the functions.php file for a theme all functionality is declared in a global scope. To clarify, this is what a typical functions file looks like:

function my_theme_do_foo() { // ... }

function my_theme_do_bar() { // ... }

add_action( 'foo_hook', 'my_theme_do_foo' );

It would seem to me that things could be "encapsulated" a little better if a class was used:

class MyTheme {
    function do_foo() { // ... }
    function do_bar() { // ... }
}

$my_theme = new MyTheme();

add_action( 'foo_hook', array( &$my_theme, 'do_foo' ) );

The advantages of the second approach (in my humble eyes):

  • Shorter function names
  • Access to instance variables (the biggest advantage IMO)
  • No global functions

The disadvantages:

  • Classname could still cause conflicts
  • Not as clear to "customize" with a child theme (would have to extend a parent class)
  • Most themes haven't done it this way, so you'd be bucking the trend

I'm probably overlooking some things, but I am wondering why not take the OOP approach? It feels a bit "cleaner" to me, if anything. Perhaps I'm mistaken?

I'm fairly new to WordPress theme development, so forgive me if this is common knowledge in the WP community :). Just trying to learn why things are the way they are.

share|improve this question
    
You can check themes from Kovshenin - wordpress.org/extend/themes/profile/kovshenin he uses OOP approach in functions.php –  Mamaduka Oct 10 '11 at 18:53
add comment

1 Answer

up vote 6 down vote accepted

Using a class for encapsulation is a very common approach by a number of developers for plugins. I do this, and I do find it cleaner. But for plugins. Themes are more procedural by nature.

We don't do it for default WordPress themes because it raises the barrier to entry. The functions are quite simple. Removing actions tied to classes can be difficult (and potentially buggy in specific circumstances).

Also, a number of functions in the default themes are pluggable. Extending a class and replacing the methods is far more complicated than just defining the function. And while two different aspects of code can replace different functions, you can't dynamically extend classes. As you pointed out, the need to extend a parent class is definitely a disadvantage.

I considered making Twenty Eleven's theme options code a class, but never got around to it. That kind of separate, plugin-like functionality seems like a good candidate for encapsulation.

share|improve this answer
    
Thanks for the answer, Nacin. I hadn't thought about the difficulty in "unhooking" actions with classes. Regarding options encapsulation - we've been thinking the same thing: github.com/jestro/struts –  Andy Adams Oct 11 '11 at 16:27
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.