Blog Hero Image

Enterprise Drupal Object Oriented Design Approach

Mar 01, 2010
Jaime Davila
Jaime Davila

It's been some time since my last post, I started in a Drupal project, so I have to learn a lot of things; one of the most interesting is its OOD/OOP - Object Oriented Design/Object Oriented Programming - approach which states that "...Drupal code base and API does reflect some principles found in object-oriented programming and design".

I'm a huge fan of OOD/OOP, I think is a great paradigm to represent the outer world, but I'm also clear about the performance problem it can caused, and I'm also sure that Procedural paradigm is more important than OO paradigm in so many ways (basically a method is a procedural block). But the current state of Web: Sites, Applications, Services, even Theory are based in OOD/OOP because it allows to recreate the problem into a more hierarchical and structural way.

Based on that let's review how Drupal implements OOD/OOP principles:

  • Modules can be thought of as classes that inherit their behavior from an abstract base class

    However, you can't inherit as the principle states: You can't create some classes and inherit from them to create a class tree. You can't do this:

    public class Test {
    private int a, b;

    public int sumOfIntegers(int a, int b) {

    public class SubTest extends Test {
    public int sumOfIntegers(int a, int b) {

    As you can see in the snippet once you instantiate SubTest class you can use its sumOfIntegers method unless you call super.sumOfIntegers which will call parents method. In Drupal something like that is not possible, for example you can't extend Views module.

    You can see an interesting forum about this here

  • Polymorphism

    Nodes are polymorphic in the classical sense...

    You can check this quote: "...polymorphism is only approximated in the rendering layer" (slide 15). It's not so surprising this quote if you analyze the previous code snippet.

  • Encapsulation

    Like most other object-oriented systems, Drupal does not have a way of strictly limiting access to an object's inner workings, but rather relies on convention to accomplish this.

    Bassically Drupal relies in prefixes as conventions, for example you shouldn't call a function call _some_function() because the underscore at the beginning means private access.

  • Abstraction

    Drupal's hook system is the basis for its interface abstraction. Hooks define the operations that can be performed on or by a module...

    This is the way Drupal implements Abstraction. What hooks offers is a way to declare a function to be executed when an action is performed, this is achieved by implementing Observer/Visitor Design Pattern.

Let's change to DataBases: DataBases has a great idea implementation: it's not a relational database however it's implemented with relationships in mind which must be set in code layer, so you can create your data base structure following that concept and creating the relationships within your code: Views follows this guidelines. However, here's a drawback, the architect should create a class diagram and a database diagram which complies with OOP guidelines, in that way any modification can be traced to data base and classes structures which in fact leads to the original goal: modification/creation of a module, node or something else needed.

As you can see, Drupal implements some of the OOD/OOP principles, however as some will notice its powers relies on the way hooks are implemented, and honestly I think they're right, hooks are a simple idea but a really elegant and efficient one.

Latest insights