Autres patterns de conception courants (Factory, Singleton, Observer, etc.)

Introduction aux patterns de conception en Node.js

Au-delà des grands principes architecturaux comme SOLID ou MVC, le développement logiciel s'appuie sur un ensemble de solutions éprouvées à des problèmes récurrents : les patterns de conception (design patterns). Ces patterns, popularisés notamment par le livre "Design Patterns: Elements of Reusable Object-Oriented Software" du Gang of Four (GoF), fournissent des modèles de solutions flexibles et réutilisables qui aident à structurer le code, améliorer sa communication et faciliter sa maintenance.

Bien que certains patterns aient été initialement décrits dans des contextes de langages fortement orientés objet comme Java ou C++, leurs principes sous-jacents sont universels et trouvent une application directe et bénéfique en Node.js. Comprendre et savoir appliquer ces patterns permet d'écrire un code JavaScript plus robuste, plus découplé et plus facile à comprendre, même sans utiliser systématiquement des classes.

Ce chapitre explore quelques-uns des patterns de conception les plus couramment rencontrés et utiles dans l'écosystème Node.js, en illustrant leur mise en oeuvre avec des exemples concrets.

Le Pattern Factory : Création d'objets flexible

Objectif : Le pattern Factory (Fabrique) vise à encapsuler la logique de création d'objets. Au lieu d'utiliser directement l'opérateur `new` pour instancier des objets spécifiques, on délègue cette responsabilité à une fonction ou une méthode 'factory'. Cela permet de découpler le code client de la connaissance des classes concrètes à instancier.

Variations : Il existe plusieurs variantes, dont le Simple Factory (une fonction unique qui retourne différents types d'objets selon un paramètre), le Factory Method (une méthode définie dans une superclasse mais implémentée dans les sous-classes pour créer des objets spécifiques) et l'Abstract Factory (une factory pour créer des familles d'objets liés).

Cas d'usage en Node.js : Créer différentes instances de connexion à une base de données (MySQL, PostgreSQL) selon la configuration, générer différents types de rapport (PDF, CSV), instancier des loggers avec différentes configurations.

// Exemple: Simple Factory pour créer des instances de Logger

class ConsoleLogger {
  log(message) { console.log(`[CONSOLE] ${message}`); }
}

class FileLogger {
  constructor(filePath) { this.filePath = filePath; }
  log(message) { console.log(`[FILE:${this.filePath}] ${message}`); /* Logique d'écriture fichier */ }
}

// La Factory
function createLoggerFactory(type, options = {}) {
  switch (type) {
    case 'console':
      return new ConsoleLogger();
    case 'file':
      if (!options.filePath) throw new Error('File path is required for file logger');
      return new FileLogger(options.filePath);
    default:
      throw new Error(`Logger type '${type}' not supported`);
  }
}

// Utilisation
const config = { loggerType: 'file', loggerOptions: { filePath: '/var/log/app.log' } };
// const config = { loggerType: 'console' };

try {
  const logger = createLoggerFactory(config.loggerType, config.loggerOptions);
  logger.log('Application démarrée.');
} catch (error) {
  console.error('Erreur configuration logger:', error.message);
}

Avantages : Réduit le couplage entre le client et les classes concrètes, simplifie l'ajout de nouveaux types de produits (il suffit de modifier la factory), centralise la logique de création.

Le Pattern Singleton : Instance unique garantie

Objectif : Le pattern Singleton garantit qu'une classe n'a qu'une seule instance et fournit un point d'accès global à cette instance.

Cas d'usage en Node.js : Gestionnaire de configuration centralisé, pool de connexions à une base de données, service de logging unique pour toute l'application.

Implémentation en Node.js : Fait intéressant, le système de modules CommonJS de Node.js (`require`) implémente naturellement une forme de Singleton pour les modules. Lorsqu'un module est chargé via `require` pour la première fois, il est exécuté, mis en cache, et les appels suivants à `require` pour le même module renverront l'instance mise en cache (`module.exports`). On peut aussi l'implémenter manuellement.

// Exemple: Singleton pour la configuration (via module caching)

// config.js
class ConfigManager {
  constructor() {
    if (ConfigManager.instance) {
      return ConfigManager.instance; // Retourne l'instance existante si elle existe déjà
    }
    console.log('Initialisation du ConfigManager (une seule fois)');
    // Charger la configuration depuis un fichier, variables d'env, etc.
    this.settings = { 
      databaseUrl: process.env.DATABASE_URL || 'mongodb://localhost/mydb',
      port: process.env.PORT || 3000 
    };
    ConfigManager.instance = this; // Stocke l'instance créée
  }

  get(key) {
    return this.settings[key];
  }
}

// On exporte une instance unique.
// Chaque fois que ce module sera 'require', la même instance sera retournée.
module.exports = new ConfigManager(); 

// --- Utilisation dans un autre fichier ---
// serviceA.js
const config = require('./config');
console.log('Service A - Port:', config.get('port'));

// serviceB.js
const config = require('./config'); // Récupère la MEME instance
console.log('Service B - DB URL:', config.get('databaseUrl'));

// Dans la console, 'Initialisation du ConfigManager...' n'apparaîtra qu'une fois.

Avantages : Contrôle strict sur l'accès à une ressource unique, économie de ressources (ex: pool de connexions).

Inconvénients : Peut introduire un état global difficile à gérer et à tester, peut masquer des dépendances, peut violer le principe de responsabilité unique si le Singleton fait trop de choses.

Le Pattern Observer : Réagir aux changements d'état

Objectif : Le pattern Observer (Observateur) établit une relation de dépendance un-à-plusieurs entre des objets. Lorsqu'un objet (le 'sujet' ou 'observable') change d'état, tous ses dépendants (les 'observateurs') sont automatiquement notifiés et mis à jour.

Cas d'usage en Node.js : C'est le coeur du modèle événementiel de Node.js ! La classe `EventEmitter` est une implémentation directe de ce pattern. On l'utilise pour les streams, les requêtes HTTP, les timers, et pour créer des systèmes d'événements personnalisés (ex: notifier d'autres parties de l'application lorsqu'un utilisateur s'inscrit).

// Exemple: Utilisation de EventEmitter
const EventEmitter = require('events');

// Le Sujet (Observable)
class UserManager extends EventEmitter {
  createUser(email) {
    console.log(`Création de l'utilisateur: ${email}`);
    // ... logique de sauvegarde en base ...

    // Emettre un événement pour notifier les observateurs
    this.emit('userCreated', { email: email, date: new Date() });
  }
}

// Les Observateurs
function sendWelcomeEmail(userData) {
  console.log(`Observateur Email: Envoi d'un email de bienvenue à ${userData.email}`);
}

function updateUserAnalytics(userData) {
  console.log(`Observateur Analytics: Mise à jour des stats pour ${userData.email} le ${userData.date}`);
}

// Enregistrement des observateurs auprès du sujet
const userManager = new UserManager();
userManager.on('userCreated', sendWelcomeEmail);       // L'observateur s'abonne
userManager.on('userCreated', updateUserAnalytics);    // Un autre observateur s'abonne

// Déclencher l'action qui change l'état et notifie
userManager.createUser('test@example.com');

// On peut aussi désinscrire un observateur
// userManager.off('userCreated', sendWelcomeEmail);

Avantages : Découplage fort entre le sujet et les observateurs (le sujet ne connaît pas les observateurs concrets), supporte la diffusion d'événements, permet d'ajouter/supprimer des observateurs dynamiquement.

Autres patterns pertinents en Node.js

D'autres patterns sont fréquemment utilisés ou pertinents dans le contexte Node.js :

Strategy (Stratégie) : Permet de définir une famille d'algorithmes, de les encapsuler et de les rendre interchangeables. Le client choisit la stratégie à utiliser au moment de l'exécution. Utile pour implémenter différentes méthodes de paiement, algorithmes de tri, stratégies de compression, etc., sans utiliser de longues structures conditionnelles.

class Order {
  constructor(amount) { this.amount = amount; }
  pay(paymentStrategy) { paymentStrategy.pay(this.amount); }
}
class CreditCardStrategy { pay(amount) { console.log(`Payé ${amount} par Carte de Crédit`); } }
class PaypalStrategy { pay(amount) { console.log(`Payé ${amount} via Paypal`); } }

const order = new Order(100);
order.pay(new CreditCardStrategy()); // Ou new PaypalStrategy()

Middleware (Intergiciel) : Bien que spécifique aux frameworks web comme Express ou Koa, c'est un pattern de conception crucial. Il permet de chaîner des fonctions pour traiter une requête HTTP séquentiellement. Chaque middleware peut modifier la requête/réponse, exécuter du code, terminer le cycle ou passer au middleware suivant. Idéal pour l'authentification, le logging, la validation, la compression, etc.

// Exemple Express Middleware
const express = require('express');
const app = express();

const loggerMiddleware = (req, res, next) => {
  console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);
  next(); // Passe au middleware/route suivant
};

const authMiddleware = (req, res, next) => {
  const apiKey = req.headers['x-api-key'];
  if (apiKey === 'secret') {
    next();
  } else {
    res.status(401).send('Unauthorized');
  }
};

app.use(loggerMiddleware); // Appliqué à toutes les routes
app.get('/public', (req, res) => res.send('Public Data'));
app.get('/private', authMiddleware, (req, res) => res.send('Private Data')); // Auth appliquée ici

app.listen(3000);

Module : Fondamental en Node.js. Il permet d'encapsuler du code (variables, fonctions) dans une unité distincte, contrôlant ce qui est exposé publiquement (`module.exports` ou `export`) et ce qui reste privé au module. Essentiel pour l'organisation, la réutilisabilité et éviter la pollution de l'espace de noms global.

Il existe bien d'autres patterns (Adapter, Decorator, Command, Facade, etc.) qui peuvent trouver leur utilité en Node.js. Le choix d'un pattern dépend toujours du problème spécifique à résoudre.

Conclusion : Choisir et utiliser les patterns à bon escient

Les patterns de conception ne sont pas des solutions miracles à copier-coller aveuglément. Ils représentent des solutions éprouvées et des vocabulaires communs pour discuter de conception logicielle. L'important est de comprendre le problème que chaque pattern cherche à résoudre et les compromis qu'il implique.

En Node.js, une bonne maîtrise de ces patterns courants, combinée aux principes d'architecture comme SOLID et à une bonne compréhension de la nature asynchrone et événementielle de la plateforme, vous permettra de concevoir et de construire des applications plus robustes, flexibles, maintenables et évolutives.

L'objectif n'est pas d'utiliser le plus de patterns possible, mais d'utiliser les bons patterns, aux bons endroits, pour répondre efficacement aux défis de conception de vos projets.