OOP In Procedural Programming

In my recent training sessions on OOP I kept on stressing that it is more about the concept rather than the multitude of keywords like class, object or interface. Essentially, these concepts can be applied even in a procedural programming language, or a language that does not support OOP through constructs and keywords and enjoy its advantages. Tim Berners Lee pointed to the document Drupal Programming from an Object Oriented Perspective. Go and read that document to understand how the concepts of OOP can be applied in procedural programming language without using the keywords and that will evaporate your myths if you have any.

Abstraction

The key is that the interface abstraction is designed using the hook system. Node is the abstraction for any content type. The core of Drupal system uses these abstractions and is hence able to handle any extended content types without code modification. The use of node_invoke() to invoke any node hook. This means that the interface for communication with any node is designed using this abstraction. Node and hook system together enable Drupal to comply with Open-Closed Principle.

The abstractions enable Dependency Inversion Principle or Inverstion Of Control encouraging loose coupling and flexibility.

Separation and Responsibilities

One of the aims of any design is to be able to separate different concerns and assign responsibilities to the right entities. Most of the complications that arise out of design are because the responsibilities are not assigned properly. This is done using nodes, modules and themes. In content management systems is very important to be able to abstract the common structure and behavior of content which can be then extended to create other content types. And at the same time allow for different behaviors of different content types.

Node is that abstraction and it exposes a consistent interface that other containers can rely on and encapsulates the common content type. The node is itself responsible for methods that operate on it, like node_view(). This lets the caller, typically a container of the node, not be responsible for the specific content type because it does not know its specifics. Similarly designing modules and themes separately allow separating display of data and its retrieval and processing.

A True CMS

That is the reason I consider Drupal a true CMS as against a featured boxed CMS. It is ready to manage content, any content, and hence can be applied to many scenarios and and many functionalities.