Gérez proprement vos modules avec la programmation orientée objet

Composition d'un module Drupal

Dans un module, toutes les fonctions sont préfixées par son nom et se retrouvent dans un fichier appelé ton_module.module. Ainsi et afin d'éviter de se retrouver avec des dossiers trop volumineux, les développeurs ont plutôt l'habitude de construire des petits fichiers ton_module.*.inc, chacun ayant une responsabilité unique. Pour utiliser une fonction de ces fichiers, plusieurs possibilité s'offrent à vous :

• Mettre une require_once au début du fichier .module
• Commencer par module_load_include() à chaque fois où vous avez besoin de la fonction
• Charger le fichier automatiquement : le cas avec hook_menu(), hook_theme() etc.

Focus sur les méthodes statiques

Si vous travaillez avec Drupal depuis un certain temps déjà, vous devriez connaître tout cela. Mais si nous voulons aller encore plus loin, nous pouvons mettre les fonctions dans des classes sous forme de méthodes statiques. Ici, les avantages sont les suivants :

• L'autoload de toutes les classes : pour cela, vous pouvez mettre les fichiers dans le .info dans les lignes files[] = ..., ou écrire votre propre class loader
• L'utilisation propre de l'espace de nom : ce n'est pas forcément une nouvelle fonctionnalité du PHP 5.3 (car il arrive que vous utilisez encore la version 5.2). Ici, vous n'avez pas besoin de préfixer les méthodes dans vos classes. Votre intelligent IDE (vim l'est aussi) vous donnera des suggestions plus pertinentes. Par exemple, si vous travaillez sur un projet "vous", avec 20 modules "vous_module1", "vous_module2"..., dans chaque module vous avez des fonctions vous_module1_fonction1, vous_module1_fonction2... Ainsi, lorsque vous taperez "vous", votre IDE va suggérer 10 fonctions qui sont toutes dans le premier module vous_module1. Nous sommes d'accord, cela n'est pas vraiment pertinent. Avec les classes séparées, votre IDE présente d'abord des classes, puis les méthodes quand vous complétez le nom de classe. Plus pratique !

Les méthodes enveloppées dans des classes ne pollue pas le scope global, elles aident aussi pour le refactoring ou le protypage ou le test. Mais l'article est trop long, donc j'arrête. Quand même, avant, pour l'info, ce paradigme est utilisé récemment dans Drupal 7 avec la classe FieldInfo (par yched et al.) et c'est très bien. Il n'y a alors pas de raison pour ne pas l'utiliser.

PS : un article sans code, mais allo quoi.

• ton_module.inc : function ton_module_faire_1() {} function ton_module_faire_2() {}

sera :

• TonModule.php : class TonModule { public static function faire_1() {} public static function faire_2() {} }