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.

I see a lot of plugins making use of object-oriented coding when there isn't really necessary.

But what's even worse is that theme developers are starting to do the same thing. Commercial themes and free popular themes like Suffusion, even my favorite theme - Hybrid, stuff all their functions inside a class, instantiate it once in functions.php and run its functions in a procedural manner :)

Wtf? What's the point of doing this? Obviously you won't be using two or more instances of the same theme, at the same time.

Let's assume that the plugins do this for the namespace (which is ridiculous), but what's the theme excuse? Am I missing something?

What's the advantage of coding a theme like this?

share|improve this question
4  
@Ambitious Amoeba - Can you explain why you believe that using classes for plugins to minimize namespace collisions is ridiculous? As for themes maybe it would be helpful too if you could give examples of what you consider good code in themes to be and what you are considering to be unnecessary. Discussing this in the abstract is not likely to achieve any insight for you or for others, especially others who are not familiar with what you are referring to. –  MikeSchinkel Dec 22 '10 at 11:04
1  
I use classes wherever i can personally, it's much easier for me to maintain, update and reuse. Personal preference aside, what good reasons are there for using a class? –  t31os Dec 22 '10 at 11:06
1  
Odd, just lost my original comment(SE bug perhaps?).. i'll repeat it though, what good reasons are there for not using a class? –  t31os Dec 22 '10 at 11:08
2  
@MikeSchinkel: you can do that by appending a prefix to the function name. I don't think it's worth the extra class overhead just to have nice function names. Anyway, I'm curious about why themes do this, not that much about plugins –  onetrickpony Dec 22 '10 at 11:11
4  
@Ambitious Amoeba - I'll certainly give that you have a right to your opinion, but my opinion differs. I believe that the clarity that classes bring to code by minimizing functions floating in the global namespace is worth what I believe to be an effectively immeasurable amount of additional overhead, especially when using a professional level IDE like PhpStorm. And classes create a self-contained unit so that the developer can know what code a module requires. And finally after evolving my WordPress plugin style to use classes, any other method just feels to me like sloppy coding. –  MikeSchinkel Dec 22 '10 at 11:19
show 5 more comments

6 Answers

up vote 22 down vote accepted

I can understand your confusion based on the example you provided. That's really a poor way to use a class ... and just because a class is used, doesn't make a system OOP.

In the case of Hybrid, they're just using a class to namespace their functions. Considering Hybrid is a theme framework, this is done so that child themes can re-use function names without the developer having to worry about name collision. In many cases, a theme framework (parent theme) is so complex, many child theme developers will never understand exactly what goes on under the hood.

If Hybrid didn't use a class structure, child theme developers would need to know what all of the existing function calls were so they could avoid re-using names. And yes, you could just prefix all of your functions with a unique slug, but that makes the code hard to read, hard to maintain, and inherently non-reusable should you develop further systems that want to make use of the same functionality.

To Answer Your Questions

Wtf? What's the point of doing this? Obviously you won't be using two or more instances of the same theme, at the same time.

No, you won't be using two or more instances of the same theme. But like I said, think of the class structure in this case as namespacing the functions, not creating a traditional object instance. Lumping everything together in a class and either instantiating it to call methods (myClass->method();) or calling methods directly (myClass::method();) is a very clean way to namespace things in a readable, reusable fashion.

Of course you could always use something like myClass_method(); instead, but if you want to re-use any of this code in another theme, in a plug-in, or in antoher framework you have to go back through and change all of your prefixes. Keeping everything in a class is cleaner and allows you to redevelop and redeploy much more quickly.

Let's assume that the plugins do this for the namespace (which is ridiculous), but what's the theme excuse? Am I missing something?

In the majority of situations I'd agree with you. However, that majority is quickly waning. I host several sites on a MultiSite installation that use variations of the same theme. Rather than re-create the same theme over and over again with minor differences, I have a single "class" for the parent theme and all of the child themes extend that class. This allows me to define custom functionality for each site while still maintaining a general sense of uniformity across the entire network.

On the one hand, theme developers may choose a class-based approach to namespace their functionality (which isn't ridiculous if you work in an environment where you re-use chunks of the same code over and again). On the other hand, theme developers may choose a class-based approach for easy extensibility by child themes.

What's the advantage of coding a theme like this?

If you're only using Hybrid on your site, there's little to know advantage for you as the end user. If you're building a child theme for Hybrid there are advantages from namespacing and extensibility. If you work for ThemeHybrid, the advantage lies in quick, efficient code reuse across your other projects (Prototype, Leviathan, etc).

And if you're a theme developer who likes a specific feature of Hybrid but not the entire theme, the advantage lies in quick, efficient code reuse in your non-Hybrid project (assuming it's also GPL).

share|improve this answer
    
I don't agree with the "extensibility" part. You have the same level of control over the parent theme as you would if you used actions and your typical functions. Why? You said it yourself, this is not true OOP. I don't agree with namespacing either - this is why I started this question in the 1st place - Try redefining any function from Hybrid in any plugin and you'll see that the functions will collide. Why do you think they still added the prefixes? :) You just can't wrap the entire theme in a class, it just doesn't make any sense... –  onetrickpony Dec 22 '10 at 16:53
    
I'm not saying to not use OOP in themes, like some people here might have understood, on the contrary (see 2.8 widgets for eg., walkers etc), but not like this. –  onetrickpony Dec 22 '10 at 17:01
1  
It seems like you have a problem with Hybrid's specific implementation, not with the practice of using OOP in themes or even using a class to namespace the functions defined in a theme. I was trying to answer your broader questions re:why do this? and re:what are the advantages of doing this? I'm not going to spend any time defending what appears to be a halfhearted implementation or arguing against your obvious animosity towards a specific theme framework's structure. Bottom line, if you don't like the way Hybrid's built, use something else. –  EAMann Dec 22 '10 at 18:34
1  
not at all, I like Hybrid (but not the class thing of course). Hybrid insipired me to create my own theme framework. Take another example, Suffusion, same type of practice. Again, namespaces in this case don't work with themes, all functions within the wrapper class will always conflict with plugins, because plugins are loaded by WP "within" themes. –  onetrickpony Dec 22 '10 at 19:33
1  
Fair enough. Just try to keep in mind that most WP work isn't OOP to begin with (since WP isn't), but putting theme methods in a class to mimic how it's done in a plug-in is at least a step in the right direction ... even if it is a half-conceived and poorly implemented class. I definitely agree that just wrapping everything in a class and calling things procedurally is a bit odd (and not useful from the POV of a 3rd party developer trying to use the system). But if done correctly (and in Hybrid it's apparently not), class-ifying your code in functions.php can be very powerful. –  EAMann Dec 23 '10 at 15:15
add comment

Oh quite the discussion! I have to admit as well that I use classes for encapsulation far more often than not. The idea being here that in my plugins, I can wrap my functions in a class, and within that class use very simple, meaningful method names that are generic even among other plugins I write. In that instance, classes are a substitute for namespaces, which I am forced to avoid for 5.2.x environments.

While there are few instances that OOP is useful for modularity, the simple act of wrapping your functions also creates the added bonus of cross-plugin extendability. For example, I recently extended an invoicing solution that was class based, and being such I could extend the main class, add extra code to various functions (w/ parent::calls) or even replace functions, all without internalizing the extended plugin.

Allas though, class wrapping for the most part is just a substitute for namespaces.

share|improve this answer
add comment

Some argue that encapsulation is the only (or at least primary) benefit that OOP offers, and that inheritance and state are somewhere between boring and evil:

http://obiecte.blogspot.com/2008/09/oop-sucks.html

The author's talking more about using classes/objects as structs than as containers for static functions, but it's interesting to read a completely different take on the question, from someone who's squarely outside of the OOP camp.

I may write my next WordPress Plugin in Haskell.

share|improve this answer
add comment

Another point to consider: Speed.

if ( !class_exists('cccYourClassName') )  
// VERSUS  
if ( !function_exists('ccc_your_function_name') )

After a short look/print out i found ~1.700 internal functions and ~1.400 user functions = ~3.100/3.200 functions VS. ~250 Classes. I guess this says the most about how much a look up would need. If you call for !function_exists('') on about 50-100 functions in your theme... just set a timer for one and then start doing some math. Even if it's not OOP it's a good way to make code

1) reuseable
2) maintainable
3) exchangeable
4) little faster

When you take a look at different classes floating around in the web that help you doing meta boxes, widgets, etc. fast, then it's good to use a controller like @toscho mentioned, because you can just plug classes out and in and just replace some lines in the controller that handles your classes.

share|improve this answer
add comment

Speed

My current base theme has 13 classes. When I build a new theme, I either use these classes as they are or I extend them. That system makes the process of building a new theme very, very fast.

Tight scopes

I rarely need global variables, because everything my code has to know is hidden in class members. So I’m able to share a variable between two very different filters or actions without the risk of collision with poorly written plugins.

Maintenance

Each class is one file. If I need to update a client’s theme, I just update some files. Whatever happens inside the classes is up to me as long as I offer the same API.

An example: above the comment_form(); call, I use a simple action:

do_action( 'load_comment_class' );
comment_form();

Which comment class will be loaded decides my controller. What exactly happens inside the comment class decides the individual class.

Try this with a pure procedural approach and you’re going nuts. :)

Readability

It is so much easier to reread and understand your own code some months later if you have separated everything by its task.

Some examples for useful class hierarchies

  • Meta_Box -> extended by Shortdesc_Meta_Box and Simple_Checkbox_Meta_Box -> extended by Sidebar_Switch
  • User_Profile_Addon -> extended by User_Profile_Checkbox (see Question 3255)
  • Comment_Form -> extended by {$theme_name}_Comment_Form
share|improve this answer
1  
Any chance to get your 'theme' classes? I want to write my own and I'd like to know how you do it. –  Horttcore Dec 22 '10 at 12:05
1  
I haven’t decided this yet. Maybe I’m realsing a new base theme together with @bueltge next year which uses some of these classes. Very likely not before march, I’m afraid. –  toscho Dec 22 '10 at 12:31
4  
Especially for your cases, free themes and frameworks, OOP is the way to go. Other people have to work with these codes. The authors should make this process as easy and flexible as possible. Replacing a class is easier than replacing 20 functions, because a well written class has a clearly defined API. –  toscho Dec 22 '10 at 13:19
2  
I can’t say anything about Hybrid; i have never used it. But, yes, a controller which organizes everything behind the curtains, offers good filters and inserts some MVC pattern into the usual theme mess – is A Good Thing. Don’t trust me. Try it. :) –  toscho Dec 22 '10 at 14:12
2  
It is time, WordPress needs a OOP theme for developers; i hope we fount the time to work for our goal. This small excerpt here and the benefits show the great possibilities with oop for customer themes; a fast way to realize a new themes ans also great for maintenance. –  bueltge Jan 2 '11 at 10:20
show 11 more comments

What's the point of complaining about code you didn't write?

If you don't like the code, write your own!

Simple. Problem solved.

Programmers like to do stuff their way. So don't presume you can tell them how to write code, what kind of whiskey to drink, what brand of cigarette to smoke, or what religion to follow. They'll just debug such diatribe and keep right on doing what they want. ;-)

Code is not poetry. Code is a variation of the Sinatra song "My Way" ...

share|improve this answer
7  
This question isn't complaining about the code, it's asking for a clear explanation of why code would be written in a particular way. Much of WP core is procedural, with a few newer features using an OOP approach. Many modern plug-ins also use OOP to encapsulate functionality. But most themes don't. The OP was asking why a pseudo-OOP approach would be used and gave Hybrid as an example. You're not answering the question, you're ranting. –  EAMann Dec 23 '10 at 15:32
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.