Principes SOLID en PHP : Comment nous les avons appliqués à un catalogue industriel réel

Introduction

Quand nous avons commencé à concevoir l'architecture de ProSilicones64 chez Portocarrero, nous avions un problème clair : le catalogue n'était pas une simple liste de produits. C'était 30 produits pouvant être fabriqués dans 19 séries de silicone différentes, chaque série avec ses propres propriétés thermiques et de dureté, applicables à 10 secteurs industriels différents, et soumis à 127 normes et certifications.

Si nous avions tout mis dans un ProductController de 2000 lignes avec des switches et des conditions, le système aurait fonctionné... pendant trois mois. Après, chaque modification aurait été un cauchemar.

Les principes SOLID nous ont donné la structure pour permettre au code de grandir. Nous ne les avons pas appliqués par purisme académique, mais parce qu'un catalogue industriel complexe a besoin d'une architecture qui reflète cette complexité sans devenir un monstre inmaintenable.

Le problème

Le WordPress que nous avons remplacé avait exactement les problèmes que SOLID prévient. Il y avait un plugin catalogue avec une classe CatalogManager qui faisait tout : requêtes produits, calcul de prix, validation de stock, génération de PDFs, envoi d'emails. 1 847 lignes dans un seul fichier.

Chaque fois que le client demandait un changement — « ajoute le secteur naval », « affiche la température maximale sur la fiche » — il fallait plonger dans ce fichier, prier pour ne rien casser, et tester manuellement parce que les tests unitaires étaient impossibles.

• 1 847 lignes dans une seule classe CatalogManager
• 34 méthodes publiques faisant tout
• 12 dépendances en dur (MySQL, mailer, logger...)
• 0 tests unitaires possibles à cause du couplage
• Chaque changement = risque de régression

C'est ce qui arrive quand on n'applique pas SRP. Et ça entraîne les autres problèmes : on ne peut pas étendre sans modifier (viole OCP), on ne peut pas substituer les composants (viole LSP), on dépend d'implémentations concrètes (viole DIP).

SRP : Chaque classe fait une seule chose

Nous avons divisé le monolithe en pièces avec des responsabilités claires

Dans ProSilicones64, les relations produit-série-secteur-norme sont le cœur du métier. Si une seule classe gère tout, n'importe quel changement aux certifications affecte le catalogue, l'exporteur, les fiches techniques. Nous avons séparé par responsabilité : chaque classe a une seule raison de changer.

<?php
class CatalogManager
{
    public function getProduct($id)
    {
        // Requête SQL directe
        $product = $this->db->query('SELECT * FROM products WHERE id = ?', [$id]);
        // Calcule le prix avec marge
        $product['price'] = $product['cost'] * 1.3;
        // Récupère les séries applicables
        $product['series'] = $this->db->query('SELECT * FROM series WHERE...');
        // Récupère les certifications
        $product['certs'] = $this->db->query('SELECT * FROM certifications WHERE...');
        // Génère le HTML de la fiche
        $product['html'] = $this->renderProductCard($product);
        // Log
        $this->logger->info('Product retrieved');
        return $product;
    }
    // ... 33 autres méthodes
}

<?php
// Requêtes produits uniquement
class ProductRepository
{
    public function findById(int $id): ?Product
    {
        return $this->db->query(
            'SELECT * FROM products WHERE id = ?', 
            [$id]
        )->fetch(Product::class);
    }
}

// Logique des séries uniquement
class SeriesService
{
    public function getForProduct(int $productId): array
    {
        return $this->seriesRepo->findByProduct($productId);
    }
}

// Validation des certifications uniquement
class CertificationValidator
{
    public function validate(Product $p, Series $s, Sector $sec): bool
    {
        $required = $sec->getRequiredCertifications();
        $available = $s->getCertifications();
        return empty(array_diff($required, $available));
    }
}

OCP : Ajouter des secteurs sans modifier le code

Ouvert à l'extension, fermé à la modification

Quand le client a dit « on ajoute le secteur naval », nous n'avons eu à toucher aucune classe existante. Chaque secteur a sa classe de prérequis implémentant une interface commune. Ajouter un secteur = créer une classe + insérer des données en BD.

<?php
class SectorValidator
{
    public function getRequirements(string $sector): array
    {
        switch ($sector) {
            case 'railway':
                return ['EN45545-2-HL2', 'EN45545-2-HL3'];
            case 'food':
                return ['FDA-21CFR177', 'EU-1935-2004'];
            case 'medical':
                return ['ISO-10993', 'USP-CLASS-VI'];
            // Chaque nouveau secteur = modifier ce switch
        }
    }
}

<?php
interface SectorRequirements
{
    public function getCertifications(): array;
    public function validateSeries(Series $series): bool;
}

class RailwaySectorRequirements implements SectorRequirements
{
    public function getCertifications(): array
    {
        return ['EN45545-2-HL2', 'EN45545-2-HL3'];
    }

    public function validateSeries(Series $series): bool
    {
        return $series->maxTemperature >= 150;
    }
}

// Ajouter le secteur naval = créer cette classe. Rien d'autre.
class NavalSectorRequirements implements SectorRequirements
{
    public function getCertifications(): array
    {
        return ['DNV-GL', 'USCG-164'];
    }

    public function validateSeries(Series $series): bool
    {
        return $series->saltWaterResistant === true;
    }
}

LSP : Tous les exporteurs sont interchangeables

Les sous-classes substituent leurs parents sans rien casser

ProSilicones64 exporte des fiches techniques en PDF, des données pour ERP en CSV, et des catalogues en XML. Tous les exporteurs implémentent la même interface : reçoivent un Product, retournent un string. Le contrôleur ne sait pas et s'en fiche du format généré.

<?php
class PdfExporter
{
    public function export($product)
    {
        return $this->pdf->generate($product); // Binaire
    }
}

class CsvExporter
{
    public function export($product)
    {
        return [$product['name'], $product['sku']]; // Array
    }
}

class XmlExporter
{
    public function export($product)
    {
        echo '<product>' . $product['name'] . '</product>'; // Affiche
    }
}

<?php
interface ProductExporter
{
    public function export(Product $product): string;
    public function getContentType(): string;
}

class PdfExporter implements ProductExporter
{
    public function export(Product $product): string
    {
        $html = $this->template->render('fiche-technique', $product);
        return $this->pdfEngine->fromHtml($html);
    }

    public function getContentType(): string { return 'application/pdf'; }
}

// Contrôleur générique qui fonctionne avec n'importe quel exporteur
class ExportController
{
    public function download(int $id, string $format): Response
    {
        $product = $this->products->findById($id);
        $exporter = $this->factory->create($format);

        return new Response(
            $exporter->export($product),
            ['Content-Type' => $exporter->getContentType()]
        );
    }
}

ISP : Interfaces petites et spécifiques

Personne ne dépend de méthodes qu'il n'utilise pas

Les vues publiques du catalogue ne font que lire. Le panel admin lit et écrit. Le système de recherche ne fait que filtrer. Au lieu d'une interface géante que tout le monde implémente, nous séparons par cas d'usage.

<?php
interface ProductRepositoryInterface
{
    public function findById(int $id): ?Product;
    public function findBySlug(string $slug): ?Product;
    public function findAll(): array;
    public function save(Product $product): void;
    public function delete(int $id): void;
    public function search(string $query): array;
    public function export(string $format): string;
    public function import(string $data): void;
    // 12 méthodes au total
}

// Le catalogue public implémente ça mais laisse 6 méthodes vides

<?php
interface ReadableProducts
{
    public function findById(int $id): ?Product;
    public function findBySlug(string $slug): ?Product;
}

interface WritableProducts
{
    public function save(Product $product): void;
    public function delete(int $id): void;
}

interface SearchableProducts
{
    public function search(string $query): array;
}

// Le catalogue public n'a besoin que de lire
class PublicCatalogController
{
    public function __construct(private ReadableProducts $products) {}
}

// L'admin a besoin de lire et écrire
class AdminController
{
    public function __construct(
        private ReadableProducts $reader,
        private WritableProducts $writer
    ) {}
}

DIP : La logique ne connaît pas l'infrastructure

Dépendre des abstractions, pas des implémentations

Le SeriesService ne sait pas si le cache est Redis, des fichiers JSON, ou de la mémoire. Il sait juste qu'il a quelque chose qui implémente CacheInterface. Changer de système de cache = changer une ligne dans le conteneur de dépendances.

<?php
class ProductService
{
    public function __construct()
    {
        // Dépendances concrètes, impossible à changer
        $this->cache = new RedisCache('localhost:6379');
        $this->db = new MySQLConnection('host=db user=root');
    }
}

<?php
interface CacheInterface
{
    public function get(string $key): mixed;
    public function set(string $key, mixed $value, int $ttl): void;
}

class ProductService
{
    public function __construct(
        private CacheInterface $cache,
        private ProductRepository $repository
    ) {}
}

// En production
$service = new ProductService(new FileCache('/var/cache'), $repo);

// En tests
$service = new ProductService(new ArrayCache(), $mockRepo);

Conclusion

Chez Portocarrero, nous n'appliquons pas SOLID parce que ça fait bien sur un CV. Nous l'appliquons parce qu'un catalogue industriel avec des relations complexes a besoin d'une architecture qui peut grandir. Si vous mettez tout dans un fichier géant, ça marchera aujourd'hui et ce sera l'enfer demain.

Les cinq principes se résument à une idée : chaque pièce fait une chose, les pièces se connectent par des contrats clairs, et ajouter une fonctionnalité signifie ajouter de nouvelles pièces, pas modifier celles qui existent.

ProSilicones64 est en production depuis six mois. Il a grandi avec trois nouveaux secteurs, deux formats d'export, une intégration ERP, et un système de fiches techniques dynamiques. Le code du premier jour fonctionne toujours sans changement. C'est ce que SOLID permet.