Drupal programming from an object-oriented perspective: This is either an example of architectural brilliance, or just lazy programmers making excuses.
Adam Kalsey turned me on to this article. In it, the creators of Drupal try to explain that while Drupal is not very object-oriented in a pure code sense, it’s object-oriented architecturally, if you transcend the code and look at the entire architecture.
Although Drupal does not make thorough use of the native OOP features of PHP, the Drupal code base and API does reflect some principles found in object-oriented programming and design.
This is a valid point? Judge for yourself with this discussion of objects (wondering if they mean “classes” here, actually).
There are many constructs in Drupal that fit the description of an “object”. Some of the more prominent Drupal components that could be considered objects are modules, themes, nodes, and users.
[…] Modules and themes are object-like as well, filling the “controller” role in many ways. Each module is a source file, but also bundles together related functions and follows a pattern of defining Drupal hooks.
Another example, this type about polymorphism:
Nodes are polymorphic in the classical sense. If a module needs to display a node, for example, it can call nodebuild() on that node, followed by drupalrender(), to get an HTML representation. The actual rendering, though, will depend on which type of node is passed to the function; this is directly analogous to having the class of an object determine its behavior when a message is sent to it. Drupal itself handles the same introspection tasks required of an OOP language’s runtime library.
I’m not sure if I buy it yet, but it doesn’t matter. I have seen very little in the Drupal codebase that would really benefit from more object-orientation. Like I mentioned when I discussed Drupal last year, it’s really a different animal. Drupal is a loose collection of code, tied together with hooks and events. It’s unlike much that I’ve ever worked with before.