Drupal and object-orientation, design against contract, and method name manipulation tricks

You can ask yourselves as coders whether you want to spend the rest of your lives imitating what underlying compilers and language constructs already do for you,
or you can embrace object-orientation, dependency injection, design against contract patterns, and get completely for free as well a complete graphical UML representation of the entire Drupal system.

I find the current Drupal API and the way it is coded so unwelcoming, that I hesitate to contribute modules at all, it makes me want to avoid any coding against it, and I just try to do whatever I can with the CMS and with contributed features. And given that I love coding and am very experienced (over 30 years) that must tell somebody something.

The Drupal API makes me absolutely starving thirst for UML-driven Java, like a man in a desert without a beer.

Dr Darren Kelly (Webel)

I wrote at http://drupal.org/node/418830#comment-2765254:

this is the kind of thing I am talking about (often elsewhere on Drupal.org as an ongoing theme) that drives me mad when working with Drupal code, nearly all of it, core and contributed, and it has nothing to do with PHP (which has excellent object-oriented support and class and interface handling features and the ability to design against interface contracts), at all, it is simply Drupal culture, a trick that has become an obsessive anti-pattern:

    // Let modules modify the view just prior to executing it.
    foreach (module_implements('views_pre_view') as $module) {
      $function = $module . '_views_pre_view';
      $function($this, $display_id, $args);
    }

I realise fully that this code comes from Views developers, and how important that module is (and how much work it does for my life). There is absolutely no need (except for in Drupal culture) to play games like that with method names. None.
There are some nice things one can do because on can manipulate function names and pass them around, but this example above is not one of them.

Just because one can manipulate functions as names and pass them around in PHP does NOT mean that it is a good idea to always do it. The code above is essentially repeating what object-oriented structures enable us to avoid. I would like every single Drupal developer to read this and know: I don't think you, any of you, should be or need to keep doing that, and I find the way Drupal is coded so bad at times that I really have to ask seriously whether I can stay with the technology, even when it now runs many sites for me (some of which ironically teach advanced graphical object-orientation for UML+Java).

I want to, seriously, completely rewrite all of Drupal from top to bottom, because I am weary of tricks like this.

Step 1: isolate this very important architectural strategy as (one or more) dedicated methods, so that the approach is decoupled from other aspect of module development. If want to take this omniprescent drupal hack (and that is what it is) and all of its drupal hook cousins and at least quarantine them (via interface operations) in methods that provide what are essentially architectural language services, so that the policy is isolated and the implementation can be varied.

Stage 2: You are then welcome to do your string concatenation hack inside that method, if you still really want to.

Stage 3: Then, module developers can develop against an architectural interface, buffered from changes in the implementation thereof, which may eventually embrace proper object orientation, or in this case calling against a method of a Module subclass employing protected hook methods (rather than a string concatenation trick that looks like a compiler working overtime).

Stage 4: module developers can then, completely robustly, move towards a completely object-oriented drupal (such as in this case invoking operations on a Module interface directly, instead of the architectural buffer).