How's your OOP?

To me, this is the one OOP tool that I miss the most in Drupal, and it thus usurps "Places we should be using OO in Drupal". Interface-centric design is the perfect way to achieve high levels of "pluggability", allow people to alter anything they want, and still have predictable behavior. I think some of the people who are voting for "Places we should be using OO in Drupal" would vote for "Interface-centric development" if they knew what it had to offer us.

I also voted where and how in Drupal but I would like to know mainly how we can develop using an editor like using eclipse that has auto complete functions with normal php. It's easy to get the ones that you need. I do remember developing with JAVA and Objects and it's so easy to just see which functions you can call upon that object :-)

For example views, I cannot get a hold of what it's capabilities are so that's one of the reasons it is so hard to get into the material. I'm sure that it's a really good thing so if we know how to develop and use the OO API And extend or create new ones in an easy manner then I predict good times!

I voted for "Theory and concepts of OOP". Many people regard "OOP" as some "language trick". Something comparable to a trick like installing some PECL library, or use of call_user_func and the likes.

However, OOP has very little to do with the language used (more on that below) and a lot with a proper mindset. OOP is more of a "way to design software" then it is "a way to develop software".
Therefore I am confident that people who "get" OOP are more likely to make better maintainable, developable, understandable and extendable modules (and core code) then people who consider it as a "programming trick".

Once people truly understand OOP, they become better software architects (IMNSHO).

However, PHP is particularly poor when it comes to OOP, compared to other web-languages, that is. So eventhough I said it has little to do with using OOP in your language, in PHP that may be slightly problematic. PHP5 comes a long way. But is nowhere near languages such as Java, Python or Ruby when it comes to OOP usage.

I am sure, however, that people truly understanding OOP design and architecture, don't need to learn or know that "in a certain Programming language". Again: it is more a way of designing software. That you have to use a -> or a ., or that singulars, attribute-readers, or inheritence is not possible, or can only be achieved using tricks, is of no concern at that point.


That's it.

If you want to attract more people to OOP and make them understand, then people need to understand how to properly write, design, and architect OOP code.

This choice is missing in the poll. But that's what I'd vote for. Interfaces are just a fraction of this topic. The problem is that - while seeing, reading, and trying to understand all the new OOP code in HEAD - most people (including me) have no idea of how one would write a new interface, a new class, new methods, new extending classes, and whatnot from scratch, in a way that works in Drupal.

It takes some time get behind Drupal's procedural hook system and understand all of its goodness and badness. I think we didn't reach the point yet where people understand the ideas and best practice design patterns behind OOP programming in and for Drupal.

To further amend this with a personal, totally uninformed consideration that recently crossed my mind:

Isn't the way how OOP works in PHP contradictory to Drupal's modular architecture? states:

An extended class is always dependent on a single base class, that is, multiple inheritance is not supported.

Doesn't that mean that there's always a 1:1 relationship, and contrary to our procedural hook architecture, classes can only be extended when implementing strangely looking abstraction layers like drupal_mail_system(), for example?
(...which still only works for one module...?)

And then there are solution attempts like, which sound like they'd strive to retain Drupal's modularity within limitations of OOP... but hey, when mentioning Faces in IRC, you get a bombsquad of Drupal core developers that are totally opposed to the idea behind it. So what?

Yay, am I talkin' BS? I have no idea! And that, I think, is the common denominator. :)

Isn't the way how OOP works in PHP contradictory to Drupal's modular architecture?

It's orthogonal to, not contradictory with. Blindly doing inheritance would be contradictory, which is why that's a bad approach as most OOP aficionados will agree. But yes, that's exactly the sort of misconception I want to try and address. OOP works best when solving problems that Drupal currently has no good solution to; and what limited solution it has (magic callbacks that we pretend are hooks but aren't) are a complete mess.

So it sounds like "so how do I actually use all this class crap?" is the running theme so far, to which the answer is "interface-centric development".

I'm not qualified to help in the decision of what topic to actually cover, but yes, given your reply and the results of this poll, a remix of both "interface-centric development" and "places to use" sounds adequate ;)

Perhaps with (yet another?) introduction into what OOP is good for in Drupal and for what it's not. Potentially also providing concrete direction, i.e. in the ultimate sense of

  1. "Is CTools' plugin system done right or contradictory to Drupal's modularity?"
  2. "Can Faces' facade pattern be done right or should we add it to the blacklist?"
  3. "Will every module exposing interfaces need to fork drupal_mail_system() to get it right?"
  4. "Interfaces? So why interfaces again?"
  5. "Are there best practices to combine OOP with regular hooks?"
  6. "So considering all of this, can we quickly write a module that implements some cool functionality in OOP, the Drupal way?"

Make sure you reserve the grand hall for this session. ;)

Yes, I am lost. And would love to see this session live. (but can't make it to DCSF, unfortunately)

In particular, I'm currently asking myself whether "adequate usage of OOP" may translate into

Whenever something should only exist once, OOP is the pattern to use.

and therefore, whether we should consider to use OOP for

  • Libraries API - one library must only be loaded once, in a single version, for the entire site
  • Wysiwyg - one editor (library) can only exist once, and on top of that, all editors need to share the same API/framework, whereas Wysiwyg module defines the interface.


For now, we won't. Just because I don't know whether it's valid to use OOP - and even if it would be valid, no idea on how to properly implement that stuff OOP-style, the Drupal way.

I have programmed in Java for more than 10 years, so I'm assuming that I would glean anything from this talk... is that a safe assumption?

I'm excited that Drupal 7 is going more OO!

Good luck with your presentations.


You may not get much out of it, true. On the other hand, the way one approaches OO in Java is legitimately different than the way one does in PHP, even though PHP's OO design is heavily Java-influenced. Also anything that is Drupal specific may be new to you.

So, um, maybe? You're not really the target audience I'm aiming for, but hopefully there will be enough splash damage that everyone will get something.

Once again, I am slated to present general Object-Oriented techniques at DrupalCon. It's an important topic; sadly a large number of Drupalers don't really "get" OO programming, but Drupal 7 is starting to make heavy use of OO. There are also an enormous number of places in Drupal where a more Object-Oriented approach would make the code vastly cleaner, simpler, and faster, if only more people thought to approach it from that standpoint.

Of course, the question is how to target such a session. I don't want to talk over people's heads, but I also don't want to waste your time with "this is a mouse"-level material.

So, I put the question out to you, future DrupalCon SF attendees. What level of technical detail would be most useful to you?

I previously talked about design patterns at both DrupalCon DC and DrupalCon Paris, so I'd like to step back a bit from that level and focus on more pragmatic, "get you up to speed" type sessions this time around. The official description reads

This session will act as an introduction to the concepts behind objects, classes, interfaces, and other mainstays of PHP object-oriented development. It will start with the basics of the concept of object-oriented programming and cover the syntax, theory, and "how to not do it wrong".

Of course, thats still a lot of material, and in only an hour I can only cover so much. So where should the emphasis be? Answer the poll and post comments for follow-up feedback. Please only respond if you are actually going to be at DrupalCon SF.