Modularity vs. Object Orientation

02 aug, 2007 | techniek | 1 Comment

I have quite some experience with design and development of CMS systems in Java for customers. Almost all plumbing I have done in this field concerned CMS implementations based on the dutch open source CMS MMBase. Additionaly, I have experience with PHP ‘CMSses’ as eZ Publish, WordPress, Nucleus CMS and Mambo.

To be able to effectively cope with the big variety in functional requirements between implementations and still reuse as much as possible, everyone agrees on the need for a modular system. Custom content types, an e-commerce shop, a forum, a guestbook, integration with back-end systems, can all be defined as ‘modules’, ‘add-ons’ or plugins.

While it is easy to dub very different requirements as ‘just another module’ on top of the generic system, it is very hard or even undoable to provide for a plug-in mechanism that allows for pluggable modules with such different scopes.

Common problems to be solved:

  • interdependency between the modules. Ideally, modules should not depend on each other. When they do, they should be aware of this and the system needs to keep track of the dependencies.
  • ease of installation. Adding a module should be as easy as a one click installation.
  • ease of de-installation. One needs to be able to remove a module without wreaking havoc on the remaining functionality.
  • ease of integration with front-end and administration interface.
  • seamless integration with the database.

I know of no system that solved all this problems but in general I find the PHP CMS’ses around provide way better extensibility and modularisation then the Java ones like MMBase.

The most powerful modularity I have met so far is provided by the open source CMS Drupal. Drupal has a very small core and the bulk of the features like authentication, meta data, templating and all end-user functions are implemented by modules. Just take a look at the impressive list of modules to understand what I mean with a wide varying module scope.

The Drupal core defines a set of hooks onto which modular callback functions can be mapped. A module in Drupal is just a bundle of callback functions, grouped into one file, that together provide a coherent unit of functionality. The way it works is very reminiscent of Aspect Oriented Programming in Java in which system cross-cutting functions are invoked from pointcuts (hooks) in the main code.
The callback functions can use every aspect of the extensive API provided by Drupal core, or other modules. Drupal registers which modules are installed, how it is ‘hooked’ into the core, and which dependencies exist on other modules. The Drupal hooks cover most aspects of the system and allow for a module to ‘inject’ code into every aspect of the system, ranging from help functions, user interactivity, administration interface, to database access.

One architectural feat of Drupal that enables for this high degree of modularity is the fact that Drupal does not implement the MVC pattern as cleanly as commonly deemed necessary. Read more on this here.
There is no strict need to define your UI strings in separate file, or to provide additional template files. This basically results in more self contained modules with less dependencies and easier to maintain.

After reading this excellent article I realized that strict object orientation not always needs to be a blessing either. Despite apparent OO benefits like strict interfaces and inheritance I think it is simply harder to build such wide-scope modularity into a Java system, or at least, I haven’t seen one yet do it as powerful as Drupal does.

Tags: ,

1 Comment


Would you like to share your thoughts?

Would you like to share your thoughts?

Geef een antwoord

@2021 Plance. All rights reserved.