PSR-4: estándar de carga automática en PHP 7

Hasta la fecha, el grupo PHP-FIG ha lanzado dos estándares de carga automática. Antes PSR-4 era PSR-0. Fue el primer estándar lanzado por el grupo PHP-FIG. Su nombre de clase tenía ciertas características de compatibilidad con versiones anteriores alineadas con un estándar PEAR aún más antiguo.
Mientras que cada nivel de la jerarquía se separó con un solo guión bajo, indicando pseudoespacios de nombres y estructura de directorios. La versión PHP 5.3 luego trajo soporte oficial de espacio de nombres para el lenguaje.

PSR-0 permitió tanto el antiguo modo de subrayado PEAR y el uso de la nueva notación de espacio de nombres. Permitir que los guiones bajos sigan durante algún tiempo facilitó la transición a los espacios de nombres y alentó una adopción más amplia. Muy pronto, Composer entró en escena.
Composer es un administrador de dependencias popular para PHP que se ocupa de paquetes y bibliotecas instalándolos en un directorio vendor/ de nuestro proyecto.

Con la filosofía del directorio vendor/ de Composer, no había un directorio principal único para las fuentes PHP como con PEAR. PSR-0 se convirtió en un cuello de botella y se marcó como obsoleto a partir de octubre de 2014.
PSR-4 es el estándar de carga automática recomendado hoy en día.
De acuerdo con PSR-4, un nombre de clase completamente calificado ahora tiene la forma según el siguiente ejemplo:

\<NamespaceName>(\<SubNamespaceNames>)*\<className>

El término clase aquí no solo se refiere a clases. También se refiere a interfaces, traits y otras estructuras similares.
Para poner esto en contexto, echemos un vistazo al código de clase parcial tomado de la plataforma de comercio Magento 2, que se muestra a continuación:

<?php
namespace Magento\Newsletter\Model;
use Magento\Customer\Api\AccountManagementInterface;
use Magento\Customer\Api\CustomerRepositoryInterface;
class Subscriber extends \Magento\Framework\Model\AbstractModel
{
// …
public function __construct(
\Magento\Framework\Model\Context $context,
\Magento\Framework\Registry $registry,
\Magento\Newsletter\Helper\Data $newsletterData,
\Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig,
\Magento\Framework\Mail\Template\TransportBuilder
$transportBuilder,
\Magento\Store\Model\StoreManagerInterface $storeManager,
\Magento\Customer\Model\Session $customerSession,
CustomerRepositoryInterface $customerRepository,
AccountManagementInterface $customerAccountManagement,
\Magento\Framework\Translate\Inline\StateInterface
$inlineTranslation,
\Magento\Framework\Model\ResourceModel\AbstractResource
$resource = null,
\Magento\Framework\Data\Collection\AbstractDb
$resourceCollection = null,
array $data = []
) {
// …
}
// …
}

La clase de suscriptor anterior se define dentro del archivo Subscriber.php presente en vendor\Magento\module-newsletter\Model\, en relación con la raíz del proyecto Magento. Podemos ver a __construct usando todo tipo de nombres de clase completamente clasificados. La plataforma Magento tiene este tipo de constructores robustos en toda su base de código debido a la forma en que maneja la inyección de dependencias. Podemos imaginar la cantidad de código adicional necesario para requerir individualmente todas estas clases manualmente si no fuera por el estándar de carga automática unificada.
El estándar PSR-4 también establece que la implementación del autocargador no debe generar una excepción ni generar un error de ningún nivel. Esto es para garantizar que los posibles cargadores automáticos múltiples no se rompan entre sí.

La guía oficial de PSR-4: Autoloader Standard está disponible en http://www.php-fig.org/psr/psr-4/.

Comparte