In terms of isolation, Drupal uses a naming convention to limit calling internal functions outside their object-like modules. This convention is maintained by the developers and thus is not as strict as the encapsulation provided by objects on their variables. Nodes in Drupal are polymorphic accepting different input and producing the desired output based on the internal construction of the item being passed on, for example, themes are displayed with a call to node_view() in spite of the fact that each theme might incorporate a different set of menus, site structure, and styling convention.

Furthermore, functions can redefine other functions within Drupal, a theme for example can benefit from the standard theme.inc file that has the main functions for Drupal interface so if the function is not overwritten the default values are rendered3. Developers creating new modules or enhancing current ones need only identify the functions that are their and create their own versions using the same naming convention. In addition to all the above, Drupal provides well defined lines that separates structure and design. In programming, application framework structures are created to handle responsibilities and assign tasks to the right entity. Issues arise when internal program work flow is not setup correctly to handle elements of the design regardless of that of the application structure. With Drupal, nodes provide the utmost abstraction and define proper set of responsibilities to avoid what others applications usually fall into.

My Conclusion

OOP is a concept, in my choice of Drupal as an example of a framework that implements object oriented programming, I wanted to emphasize on the concept of OOP more than the implementation. From what has been discussed above, Drupal has more functions and procedure than it has objects and classes, however, all aspects of a well defined OOP application has been constructed using what was available to the developers at the time when the application was created. OOP is a way of thinking, even if the language is not equipped with a preset of objects and classes, developers can build modules and functions that allow interoperability, inheritance, and encapsulation. I could be wrong, but even a markup language like HTML allows for some modularity in its structure to leave room for reuse, inheritance, and interoperability. I am not saying HTML is an OOP language, I know many does not even consider it as a language, however, I think the characteristics of modular development and object orientation can be incorporated as part of the implementation. A very important element in Drupal is its expandability and its mind set anti-backward compatibility policy which generally affects many of the applications available in the market and results in many becoming too rigid or unexpectedly break and become fragile.
Drupal, as of this writing, has released version 7 which benefits from the advanced object oriented elements of PHP 5. We should expect a drastic change in the functional structure of Drupal by incorporating more classes and objects to simplify some of what has been master minded in earlier versions without actual OOP tools .

Drupal has a much cleaner core design and a very good API and theme engine. It impresses every developer with the capabilities it has in terms of organization and modularity. If there is one thing Drupal proves it would be that not every program using classes is an OO program, and not every procedural function means spaghetti code.