Introduction
Dans un projet Drupal, les modules sont des extensions qui ajoutent ou modifient des fonctionnalités. Ils sont souvent installés dans le répertoire web/modules/contrib, qui contient des modules téléchargés à partir de la communauté Drupal ou de sources tierces. Ces modules fournissent des fonctionnalités supplémentaires pour répondre à des besoins spécifiques.
Cependant, dans certains cas, vous pouvez avoir besoin de fonctionnalités sur mesure qui ne sont pas couvertes par les modules disponibles dans contrib. Pour cela, vous pouvez créer vos propres modules personnalisés. Ces modules se trouvent dans le répertoire web/modules/custom, que nous avons créé au même niveau que le dossier contrib pour y stocker nos modules personnalisés.
Dans cette documentation, nous allons vous guider à travers la création d’un module personnalisé dans Drupal 10, tout en appliquant les principes SOLID pour garantir un code maintenable, flexible et bien structuré.
Prérequis
Avant de commencer la configuration, vous devez disposer d’un environnement Drupal fonctionnel. Pour des instructions détaillées sur l’installation de Drupal, veuillez vous référer à Comment installer Drupal dans un conteneur docker
Use Case
Nous allons créer un service de journalisation pour Drupal 10 qui enregistre des messages chaque fois qu’un nouveau contenu est inséré. Ce service utilise le canal de journalisation custom_solid_module pour centraliser les messages de log. Il garantit que chaque ajout de contenu génère un message de log, tout en assurant une architecture extensible et conforme aux principes SOLID, notamment le principe de Responsabilité unique (SRP), en isolant la logique de journalisation du reste de l’application.
Les Principes SOLID
Avant de commencer à créer un module personnalisé, il est important de comprendre les principes SOLID, qui permettent de structurer un code de manière à le rendre plus maintenable, modulaire et évolutif. Ces principes sont couramment utilisés en développement orienté objet (OO) pour assurer la qualité du code.
- S – Single Responsibility Principle (SRP)
Chaque classe ou module ne doit avoir qu’une seule responsabilité ou raison de changer. Cela permet de simplifier les modifications et d’éviter les effets de bord. - O – Open/Closed Principle (OCP)
Une entité logicielle (classe, module, etc.) doit être ouverte à l’extension mais fermée à la modification. Il faut favoriser l’ajout de nouvelles fonctionnalités via l’extension, sans changer le comportement interne de l’entité. - L – Liskov Substitution Principle (LSP)
Les sous-classes ou les dérivations doivent pouvoir remplacer leurs classes parentes sans altérer la validité du programme. Autrement dit, une classe dérivée doit pouvoir être utilisée comme si elle était la classe de base. - I – Interface Segregation Principle (ISP)
Il est préférable d’avoir plusieurs interfaces spécifiques à des clients plutôt qu’une seule interface générale. Cela permet d’éviter les implémentations inutiles et de maintenir des interfaces cohérentes. - D – Dependency Inversion Principle (DIP)
Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau, mais des abstractions. Les détails doivent dépendre des abstractions, et non l’inverse, afin de réduire le couplage.
Si vous souhaitez approfondir vos connaissances sur les principes SOLID et leur application pratique, vous pouvez consulter la formation suivante Les principes SOLID : Fondements pour un code logiciel robuste et évolutif.
Créer la structure du module
Commencez par créer le répertoire de votre module personnalisé custom_solid_module dans le dossier modules/custom. La structure de base du module ressemble à ceci :
custom_solid_module/
├── custom_solid_module.info.yml
├── custom_solid_module.module
├── custom_solid_module.services.yml
└── src/
└── Service/
└── LoggerService.phpcustom_solid_module.info.yml: fichier de description du modulecustom_solid_module.services.yml: fichier pour déclarer les services.src/Service/LoggerService.php: service PHP respectant les principes SOLID.custom_solid_module.module: fichier pour les hooks de base (si nécessaire).
Créer le Fichier d’Informations
Le fichier .info.yml est essentiel pour que Drupal reconnaisse votre module. Il doit contenir des informations de base sur le module. Créez le fichier custom_solid_module.info.yml et ajoutez-y le contenu suivant :
name: 'Custom Solid Module' type: module description: 'A custom module following SOLID principles.' package: Custom core_version_requirement: ^10 dependencies: - drupal:system
Ce fichier définit les informations de base du module, y compris son nom, sa description et ses dépendances.
Configurer les Services
Les services sont essentiels pour respecter les principes SOLID, en particulier le principe de responsabilité unique. Chaque service doit avoir une tâche spécifique. Créez le fichier custom_solid_module.services.yml et ajoutez-y le service LoggerService :
services:
custom_solid_module.logger_service:
class: Drupal\custom_solid_module\Service\LoggerService
arguments: ['@logger.factory']
Ici, nous déclarons un service appelé LoggerService, en injectant un service de journalisation (log) pour suivre les actions du module.
Créer la Classe de Service
Dans le dossier src/Service/, créez un fichier LoggerService.php pour définir la logique du service.
<?php
namespace Drupal\custom_solid_module\Service;
use Drupal\Core\Logger\LoggerChannelFactoryInterface;
/**
* Logger service class that handles logging.
*/
class LoggerService {
protected $logger;
/**
* LoggerService constructor.
*
* @param \Drupal\Core\Logger\LoggerChannelFactoryInterface $logger_factory
* The logger channel factory service.
*/
public function __construct(LoggerChannelFactoryInterface $logger_factory) {
// Crée un canal de journalisation personnalisé pour votre module.
$this->logger = $logger_factory->get('custom_solid_module');
}
/**
* Logs a simple message.
*/
public function logMessage() {
$this->logger->info('This is a log message from LoggerService.');
}
}
Dans cet exemple, nous avons un service qui s’occupe uniquement de la journalisation, ce qui respecte le principe de responsabilité unique (SRP). Le service est déclaré dans le fichier .services.yml et peut être utilisé dans d’autres parties du module.
Utilisation des Hooks
Le fichier .module permet d’implémenter des hooks, des points d’entrée dans Drupal pour réagir à certains événements. Bien que nous suivions les principes SOLID, certains comportements doivent être gérés via des hooks. Créez le fichier custom_solid_module.module et ajoutez le code suivant pour implémenter un hook :
<?php
/**
* Implements hook_help().
*
* Provides module help information.
*/
function custom_solid_module_help($route_name, $route_match) {
switch ($route_name) {
case 'help.page.custom_solid_module':
return '<p>' . t('This is the help page for the Custom Solid Module.') . '</p>';
}
}
/**
* Implements hook_entity_insert().
*
* Reacts to entity creation.
*/
function custom_solid_module_entity_insert(\Drupal\Core\Entity\EntityInterface $entity) {
if ($entity->getEntityTypeId() == 'node') {
// Utilise le service LoggerService pour journaliser l'événement.
\Drupal::service('custom_solid_module.logger_service')->logMessage();
}
}
Ici, le hook hook_entity_insert() réagit à la création d’un contenu. Cependant, la logique métier (journalisation) est déléguée à un service, respectant ainsi les principes SOLID.
Tester le Module
Activez votre module dans Drupal via la ligne de commande avec drush en custom_solid_module ou en utilisant l’interface graphique :
Ensuite, vous pouvez tester le module en créant un nouveau contenu. Le service LoggerService journalisera l’événement dans les logs du système, que vous pouvez consulter en accédant à /admin/reports/dblog.
Conclusion
La création d’un module personnalisé dans Drupal 10 en appliquant les principes SOLID permet de concevoir des solutions robustes, évolutives et maintenables. Le principe de Responsabilité unique (SRP) garantit que chaque composant du module a une fonction bien définie, simplifiant ainsi la gestion et l’évolution du code. Le principe Ouvert/Fermé (OCP) offre la possibilité d’étendre les fonctionnalités sans altérer la base du code, assurant une grande flexibilité. Enfin, le principe Inversion des dépendances (DIP) permet de rendre le module indépendant de ses implémentations concrètes, facilitant ainsi les évolutions futures. En respectant ces principes, vous créez un module capable de s’adapter aux besoins du projet tout en restant facile à maintenir.
Développeuse fullstack spécialisée en Systèmes d'Information Répartis , diplômée de la section informatique de la Faculté des Sciences et Techniques (FST) de l'UCAD. Je relève avec passion des défis complexes, avec une forte capacité d'adaptation et un engagement pour la collaboration en équipe. Toujours avide d'apprendre, je vise à créer un impact positif et à promouvoir l'excellence organisationnelle dans chaque projet.
