3.3Namespaces, autoloading y Composer
Lo esencial en 30 segundos
- Los namespaces evitan colisiones : namespace App\Modèles; al inicio, use para importar — dos User coexisten en espacios distintos.
- El autoloading elimina inclusiones : convención PSR-4 (namespace → carpetas/archivos), la clase se carga en su primer uso.
- Composer conecta al ecosistema : composer.json declara, composer install descarga en vendor/ (no versionado) + autoloader, composer.lock fija.
Mini-caso hilado — Riad sale del infierno de los require
Riad, desarrollador web en Constantine, malabarea con cuarenta require manuales y una colisión entre su clase Email y la de una biblioteca de envío. Ordena sus clases en namespaces App\Boutique, adopta el autoloading PSR-4 (namespace = ruta de archivo), inicializa Composer, instala la biblioteca vía composer require y ya solo carga un único require 'vendor/autoload.php'. Fin de las inclusiones, fin de las colisiones.
Este mismo caso vuelve en el curso, el esquema, el guion y el reto 48h.
1. Namespaces y autoloading PSR-4
Cuando el proyecto crece, dos problemas : conflictos de nombres (dos clases User) e inclusiones manuales inmanejables. Los namespaces organizan las clases en espacios lógicos, como carpetas : App\Modèles\User y Fournisseur\Auth\User coexisten. Se declara arriba (namespace App\Modèles;) y se importa con use App\Modèles\User;.
El autoloading carga automáticamente el archivo de una clase en su primer uso, vía la convención PSR-4 : el namespace corresponde a la estructura carpetas/archivos (App\Modèles\User → src/Modèles/User.php). Fin de las listas de require : Riad ya no incluye nada a mano, el autoloader encuentra solo el archivo correcto.
2. Composer : dependencias y ecosistema
Composer es el gestor de dependencias de PHP (el equivalente de npm) : se declara en composer.json, composer install descarga en vendor/ y genera el autoloader (require 'vendor/autoload.php'; carga todo). Da acceso a Packagist, repositorio inmenso de bibliotecas probadas (email, PDF, HTTP) — se instala en lugar de recodificar.
Como con npm : NO se versiona vendor/ (regenerable vía install) y composer.lock bloquea las versiones exactas (reproducibilidad). Riad retiene el paralelo node_modules/package-lock : misma disciplina, mismos reflejos. Todos los frameworks (Laravel, Symfony) descansan sobre esta base.
🔎 Ejemplo concreto — Namespace, PSR-4 y autoloader Composer
Riad organiza su clase y carga todo en una línea.
email; }
}
// punto de entrada : una sola carga
require 'vendor/autoload.php';
use App\Modeles\Utilisateur;
$client = new Utilisateur('riad@exemple-fictif.test');Lectura : namespace declarado, autoloader único, import por use, instanciación directa.
Lección : ningún require manual del archivo de clase — la convención hace el vínculo.
Vocabulario de la sección
- Namespaces
- Espacios lógicos que organizan las clases y evitan conflictos ; declaración namespace al inicio, import con use.
Ejemplo sencillo: App\Modèles\User vs Fournisseur\Auth\User en casa de Riad.
Lo que no es: nombres prefijados a mano para evitar colisiones.
Reflejo: usar namespaces desde la primera clase de un proyecto.
- Autoloading (PSR-4)
- Carga automática del archivo de una clase al usarse, vía la convención namespace → carpetas/archivos.
Ejemplo sencillo: App\Modèles\User encontrado en src/Modèles/User.php.
Lo que no es: cuarenta require manuales al inicio del script.
Reflejo: respetar estrictamente la convención PSR-4.
- Composer
- Gestor de dependencias PHP : instalar bibliotecas, gestionar versiones y autoloader ; ha transformado el ecosistema.
Ejemplo sencillo: El composer require de la biblioteca de envío de Riad.
Lo que no es: ZIP descargados e incluidos a mano.
Reflejo: instalar vía Composer, nunca a mano.
- composer.json / vendor / lock
- composer.json declara ; install descarga en vendor/ (no versionado, regenerable) + autoloader ; composer.lock fija las versiones.
Ejemplo sencillo: El lock versionado, el vendor/ ignorado en casa de Riad.
Lo que no es: un vendor/ versionado con miles de archivos.
Reflejo: versionar json + lock, ignorar vendor/.
- Packagist / ecosistema
- Repositorio de paquetes PHP : miles de bibliotecas reutilizables — instalar probado en lugar de recodificar.
Ejemplo sencillo: La biblioteca de envío SMTP instalada en un comando.
Lo que no es: reescribir su propio envío de email frágil.
Reflejo: buscar lo probado antes de codificar casero.
En la práctica — Organizar y conectar un proyecto moderno
- Declarad namespaces (`namespace App\Modèles;`) para organizar vuestras clases y evitar conflictos ; importad con `use`.
- Inicializad Composer (`composer init`) y comprended el autoloading PSR-4 (namespace → carpetas) : ya no hace falta incluir cada clase.
- Instalad una biblioteca externa (`composer require ...`) y usadla vía el autoloader (`require 'vendor/autoload.php';`).
- Recordad : no versionar vendor/ (regenerable), composer.lock fija las versiones — como node_modules/package-lock para npm.
Guion listo para decir — presentar su proyecto estructurado (30 s)
« El proyecto usa namespaces bajo App, en PSR-4 : cada clase se carga automáticamente. Las dependencias pasan por Composer, instaladas en vendor no versionado, versiones fijadas por el lock. Un solo require del autoloader en entrada. »
Para decir en revisión ; mostrar la arborescencia y el composer.json.
Modelo copiar-pegar — composer.json PSR-4 mínimo
{
"name": "riad/boutique",
"require": {
"php": ">=8.1"
},
"autoload": {
"psr-4": {
"App\\": "src/"
}
}
}
// Luego : composer install
// Entrada : require 'vendor/autoload.php';Independiente
Un composer.json PSR-4 basta para ordenar las clases de presupuestos.
PYME en Constantine
Riad aplica namespaces a la tienda por módulo para que dos equipos codifiquen sin colisión.
Equipo de producto
Imponer PSR-4 + lock versionado para installs reproducibles en todas partes.
Principiante
Esta semana : un namespace, dos clases autocargadas, cero require manual.
✓ Buenas prácticas
- Usar namespaces desde el inicio (evitar colisiones futuras).
- Respetar PSR-4 al pie de la letra (namespace = ruta de archivo).
- Instalar probado vía Composer en lugar de recodificar.
✗ Errores frecuentes
- Versionar vendor/ (repositorio contaminado, conflictos binarios).
- Incluir las clases a mano en lugar del autoloader.
- Olvidar el lock (versiones flotantes, installs no reproducibles).
Puntos clave
- NAMESPACES : espacios lógicos anti-conflictos (dos User coexisten). namespace + use para importar.
- AUTOLOADING (PSR-4) : carga auto vía convención namespace → carpetas. Fin de las inclusiones manuales.
- COMPOSER = gestor de DEPENDENCIAS (como npm) : instalar, versionar, generar el autoloader. composer.json, vendor/ (no versionado), composer.lock (fijado).
- BASE del PHP moderno y profesional (todos los frameworks) : organizar proyectos grandes, cargar auto, explotar Packagist.
Reto 48h — aplica mañana
Aplicad namespaces a 2 clases en PSR-4 cargadas por 1 autoloader, e instalad 1 biblioteca vía Composer.
- Declaro e importo namespaces sin dudar.
- Mis clases se cargan sin require manual.
- Mi vendor/ está ignorado, mi lock está versionado.
Preguntas frecuentes
¿Qué cambia realmente Composer y por qué es central?
Antes de Composer : descargas manuales, inclusiones a mano, versiones gestionadas por uno mismo — ecosistema artesanal. Después : instalación en un comando con resolución de dependencias, acceso a Packagist (miles de bibliotecas probadas), versiones gestionadas (lock reproducible) y autoloader generado. Es el equivalente de npm : el paso del PHP artesanal al PHP profesional.
¿Por qué namespaces y autoloading funcionan juntos?
Los namespaces resuelven los conflictos (prefijo lógico : dos User coexisten), el autoloading resuelve las inclusiones (carga auto). El vínculo : la convención PSR-4 hace corresponder namespace y ruta de archivo — el autoloader deduce el archivo desde el nombre completo de la clase. Organizar (namespaces) + cargar (autoloading) : un sistema único y limpio.
¿Qué archivo declara las dependencias y el autoloading PSR-4?