3.3Namespaces, autoloading & Composer
L'essentiel en 30 secondes
- Les namespaces évitent les collisions : namespace App\Modèles; en tête, use pour importer — deux User coexistent dans des espaces différents.
- L'autoloading supprime les inclusions : convention PSR-4 (namespace → dossiers/fichiers), la classe se charge à son premier usage.
- Composer connecte à l'écosystème : composer.json déclare, composer install télécharge dans vendor/ (non versionné) + autoloader, composer.lock fige.
Mini-cas filé — Riad sort de l'enfer des require
Riad, développeur web à Constantine, jongle avec quarante require manuels et une collision entre sa classe Email et celle d'une bibliothèque d'envoi. Il range ses classes en namespaces App\Boutique, adopte l'autoloading PSR-4 (namespace = chemin de fichier), initialise Composer, installe la bibliothèque via composer require et ne charge plus qu'un seul require 'vendor/autoload.php'. Fini les inclusions, fini les collisions.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h.
1. Namespaces et autoloading PSR-4
Quand le projet grandit, deux problèmes : les conflits de noms (deux classes User) et les inclusions manuelles ingérables. Les namespaces organisent les classes en espaces logiques, comme des dossiers : App\Modèles\User et Fournisseur\Auth\User coexistent. On déclare en haut (namespace App\Modèles;) et on importe avec use App\Modèles\User;.
L'autoloading charge automatiquement le fichier d'une classe à son premier usage, via la convention PSR-4 : le namespace correspond à la structure dossiers/fichiers (App\Modèles\User → src/Modèles/User.php). Fini les listes de require : Riad n'inclut plus rien à la main, l'autoloader trouve le bon fichier tout seul.
2. Composer : dépendances et écosystème
Composer est le gestionnaire de dépendances de PHP (l'équivalent de npm) : on déclare dans composer.json, composer install télécharge dans vendor/ et génère l'autoloader (require 'vendor/autoload.php'; charge tout). Il donne accès à Packagist, dépôt immense de bibliothèques éprouvées (e-mail, PDF, HTTP) — on installe au lieu de recoder.
Comme pour npm : on ne versionne PAS vendor/ (régénérable via install) et composer.lock verrouille les versions exactes (reproductibilité). Riad retient le parallèle node_modules/package-lock : même discipline, mêmes réflexes. Tous les frameworks (Laravel, Symfony) reposent sur ce socle.
🔎 Exemple concret — Namespace, PSR-4 et autoloader Composer
Riad organise sa classe et charge tout en une ligne.
email; }
}
// point d'entree : un seul chargement
require 'vendor/autoload.php';
use App\Modeles\Utilisateur;
$client = new Utilisateur('riad@exemple-fictif.test');Lecture : namespace déclaré, autoloader unique, import par use, instanciation directe.
Leçon : aucun require manuel du fichier de classe — la convention fait le lien.
Vocabulaire de la section
- Namespaces
- Espaces logiques organisant les classes et évitant les conflits ; déclaration namespace en tête, import avec use.
Exemple simple : App\Modèles\User vs Fournisseur\Auth\User chez Riad.
Ce que ce n'est pas : des noms préfixés à la main pour éviter les collisions.
Réflexe : namespacer dès la première classe d'un projet.
- Autoloading (PSR-4)
- Chargement automatique du fichier d'une classe à son usage, via la convention namespace → dossiers/fichiers.
Exemple simple : App\Modèles\User trouvé dans src/Modèles/User.php.
Ce que ce n'est pas : quarante require manuels en tête de script.
Réflexe : respecter strictement la convention PSR-4.
- Composer
- Gestionnaire de dépendances PHP : installer des bibliothèques, gérer versions et autoloader ; a transformé l'écosystème.
Exemple simple : Le composer require de la bibliothèque d'envoi de Riad.
Ce que ce n'est pas : des ZIP téléchargés et inclus à la main.
Réflexe : installer via Composer, jamais à la main.
- composer.json / vendor / lock
- composer.json déclare ; install télécharge dans vendor/ (non versionné, régénérable) + autoloader ; composer.lock fige les versions.
Exemple simple : Le lock commité, le vendor/ ignoré chez Riad.
Ce que ce n'est pas : un vendor/ commité de milliers de fichiers.
Réflexe : versionner json + lock, ignorer vendor/.
- Packagist / écosystème
- Dépôt de paquets PHP : milliers de bibliothèques réutilisables — installer de l'éprouvé au lieu de recoder.
Exemple simple : La bibliothèque d'envoi SMTP installée en une commande.
Ce que ce n'est pas : réécrire son propre envoi d'e-mail fragile.
Réflexe : chercher l'éprouvé avant de coder maison.
En pratique — Organiser et connecter un projet moderne
- Déclarez des namespaces (`namespace App\Modèles;`) pour organiser vos classes et éviter les conflits ; importez avec `use`.
- Initialisez Composer (`composer init`) et comprenez l'autoloading PSR-4 (namespace → dossiers) : plus besoin d'inclure chaque classe.
- Installez une bibliothèque externe (`composer require ...`) et utilisez-la via l'autoloader (`require 'vendor/autoload.php';`).
- Retenez : ne pas versionner vendor/ (régénérable), composer.lock fige les versions — comme node_modules/package-lock pour npm.
Script prêt à dire — présenter son projet structuré (30 s)
« Le projet est namespacé sous App, en PSR-4 : chaque classe se charge automatiquement. Les dépendances passent par Composer, installées dans vendor non versionné, versions figées par le lock. Un seul require de l'autoloader en entrée. »
À dire en revue ; montrer l'arborescence et le composer.json.
Modèle copier-coller — composer.json PSR-4 minimal
{
"name": "riad/boutique",
"require": {
"php": ">=8.1"
},
"autoload": {
"psr-4": {
"App\\": "src/"
}
}
}
// Puis : composer install
// Entree : require 'vendor/autoload.php';Indépendant
Un composer.json PSR-4 suffit à ranger les classes de devis.
PME à Constantine
Riad namescape la boutique par module pour que deux équipes codent sans collision.
Équipe produit
Imposer PSR-4 + lock commité pour des installs reproductibles partout.
Débutant
Cette semaine : un namespace, deux classes autoloadées, zéro require manuel.
✓ Bonnes pratiques
- Namespacer dès le départ (éviter les collisions futures).
- Respecter PSR-4 à la lettre (namespace = chemin de fichier).
- Installer de l'éprouvé via Composer plutôt que recoder.
✗ Pièges fréquents
- Versionner vendor/ (dépôt pollué, conflits binaires).
- Inclure les classes à la main au lieu de l'autoloader.
- Oublier le lock (versions flottantes, installs non reproductibles).
Points clés à retenir
- NAMESPACES : espaces logiques anti-conflits (deux User coexistent). namespace + use pour importer.
- AUTOLOADING (PSR-4) : chargement auto via convention namespace → dossiers. Fini les inclusions manuelles.
- COMPOSER = gestionnaire de DÉPENDANCES (comme npm) : installer, versionner, générer l'autoloader. composer.json, vendor/ (non versionné), composer.lock (figé).
- SOCLE du PHP moderne et professionnel (tous les frameworks) : organiser gros projets, charger auto, exploiter Packagist.
Défi 48h — appliquez demain
Namespacer 2 classes en PSR-4 chargées par 1 autoloader, puis installez 1 bibliothèque via Composer.
- Je déclare et j'importe des namespaces sans hésiter.
- Mes classes se chargent sans require manuel.
- Mon vendor/ est ignoré, mon lock est commité.
Questions fréquentes
Qu'est-ce que Composer change vraiment, et pourquoi est-il central ?
Avant Composer : téléchargements manuels, inclusions à la main, versions gérées soi-même — écosystème artisanal. Après : installation en une commande avec résolution des dépendances, accès à Packagist (milliers de bibliothèques éprouvées), versions gérées (lock reproductible) et autoloader généré. C'est l'équivalent de npm : le passage du PHP artisanal au PHP professionnel.
Pourquoi namespaces et autoloading fonctionnent-ils ensemble ?
Les namespaces résolvent les conflits (préfixe logique : deux User coexistent), l'autoloading résout les inclusions (chargement auto). Le lien : la convention PSR-4 fait correspondre namespace et chemin de fichier — l'autoloader déduit le fichier depuis le nom complet de la classe. Organiser (namespaces) + charger (autoloading) : un système unique et propre.
Quel fichier déclare les dépendances et l'autoloading PSR-4 ?