Open Source Network Blog

Jisse Reitsma

Jisse Reitsma is co-founder of Jira ICT, wrote a book on Joomla! Templates, teaches many courses and programs in Joomla!, Magento and Drupal. Authors profile

Drupal 7 is on the way. It will ship with a lot of new features like an integrated WYSIWYG-editor, automatic upgrades and CCK as a core-module, but the biggest improvement seems to be usability. But it will only support PHP version 5. Does Drupal 7 take a different approach towards OOP (Object-Oriented Programming)? Let's have a look at Drupals approach towards objects and classes.

Drupal modules and hooks

For a long time Drupal has had a very peculiar approach towards objects and classes. While object-oriented programming is for many the one and only choice for creating design patterns, Drupal die-hards have always claimed that design patterns are implemented in Drupal but just not with objects and classes. Drupal is referred to as OOD (Object Oriented Design) and not OOP (Object Oriented Programming).This is true, but slowly OOP has infiltrated the Drupal CMS, and Drupal 7 is just evidence of this process.

For those who don't know how Drupal works, I'm going to explain some basics of Drupal programming: Drupal includes a core (which is written with procedural code) and modules. Modules consist out of functions and these functions follow certain naming conventions, that allow them to be called dynamically by the Drupal core.

Functions by naming conventions

For instance if you want to add menu-items from your own module you would include a function MODULE_menu() and define an array-structure describing your menu-items within. Drupal will include your module-script and discover the definition of this function. Through the naming conventions it will see that your MODULE_menu() function is "implementing a menu-hook" and thus should be called when creating the menu.

If the same hooking-system would be built with classes, again naming conventions would be needed to allow for this dynamic behaviour. It could be argued that for the sake of hooks, it doesn't matter whether classes or stand-alone functions are used.

You can read more about this whole discussion here.

The benefit of classes and objects

Working with classes and objects gives the benefit of inheritance though, and because of this the PHP-code needed to be written is - if well written - much easier to understand. Though Drupal offers much more flexibility in modifying core elements (forms, menus, themes, database queries) then other webapplications like Joomla! 1.5 or Magento, the code being produced lacks beauty and readibility.

Interestingly the very popular modules CCK (Content Construction Kit) and Views have made use of objects already some time, while still using the procedural hook-system to integrate with the Drupal core. And these modules offer functionality so good that they may become part of the Drupal 7 core distribution. Some Drupal die-hards say however that these modules contain inconsistent code - some kind of half-breed between procedural and object-oriented code and thus are not the perfect example of introducing OOP in Drupal.

Among the coders a lot of initiatives are out there to offer a more OOP-approach. There are even projects that allow you to plugin your code deep into the Drupal core. But asking the developers to just rewrite the module-system from being based upon functions into being based upon classes, is asking them to rewrite a new CMS.

Let's check out Drupal 7 OOP

Enough about the discussion whether OOP benefits the world. Let's see how Drupal 7 differs from previous Drupal versions and let's see what approach it takes towards objects and classes. The Drupal core exists out of two groups of scripts: The include-files in the folder includes and the core-modules in the folder modules.

With the include-files nothing has changed much except for one major change: The original database-functions have been replaced by a new database abstraction layer (DAL). And guess what? Yes, it is OOP. The database layer extends the PDO (PHP Data Objects) extension - a PHP5 native extension - which uses object-oriented code to access databases. The big benefit is that it is much easier to create new connections to different database-types (Microsoft SQL, PostGRESQL, they all come in the picture).

One big thing to notice here is that the only reason why Drupal makes use of object-oriented code in this case, is to reuse existing functionality from other open-source projects (in this case a PHP core-extension).

OOP in the Drupal core-modules?

When we move to the core-modules and check for objects and classes, the first thing that jumps into sight is a huge number of files ending with ".test" and containing a class extending DrupalWebTestCase, TaxonomyWebTestCase or FileTestCase. It's not really fair to call Drupal 7 OOP because of this: These are all classes extending SimpleTest - a common PHP-class to allow for easy unit testing of PHP-fragments.

That concludes our search for OOP in Drupal 7. Basically the only real object-oriented piece of Drupal 7 so far is the database layer (containing classes with abvious names like Database and Query). But it seems that Drupal takes it up against the large majority of programmers that find OOP the best way to go. Good on you, Drupal.

Does Drupal 7 turn OOP? No!