Partage

Qu’est ce que les PSRs et à quoi servent-ils ?


Les Regles du PHP, PSR

Qu’est ce que les PSRs et à quoi servent-ils ?

PSR est l’abréviation de PHP Standards Recommandation. Il s’agit d’un regroupement de standards et de conventions. L’objectif principal est de réunir les différentes méthodes de programmation présentes à travers les frameworks et CMS existants en PHP (Symfony, Laravel, PHP Natif, …).

Post last updated: 9 février 2021

Introduction

PSR est l’abréviation de PHP Standards Recommandation. Il s’agit d’un regroupement de standards et de conventions. L’objectif principal est de réunir les différentes méthodes de programmation présentes à travers les frameworks et CMS existants en PHP (Symfony, Laravel, PHP Natif, …). Ces conventions sont gérées par un groupe nommé PHP-Fig : ils créent, modifient ou suppriment les standards permettant de générer une uniformité parmi les différents projets réalisés en PHP.

Conventions PHP

Chaque PSR est associé à un numéro et représente un dépôt contenant une liste de conventions ou diverses interfaces permettant d’améliorer la coopération entre Développeurs PHP. Ces interfaces sont fonctionnelles dans leur état actuel mais restent néanmoins personnalisables selon le besoin. Il existe une liste assez conséquente de PSR dont certains encore en “draft” (en attente de validation ou de développement). Parmi ceux-ci, la partie qui nous intéresse est la liste “active”. Il s’agit de la liste validée par PHP-Fig et qui doit être mise en place durant la programmation d’un projet en PHP. Cette liste est en constante évolution et sera amenée à changer avec le temps.

Voici donc la liste actuelle valide expliquée de manière concise :

PSR 1 Basic Coding Standard “Rassemblons les standards”

Le PSR 1 correspond aux conventions standards de programmation liées au PHP. Il est constitué de 7 règles :

  • Les fichiers PHP doivent démarrer avec .
  • L’encodage doit être en UTF-8 sans BOM.
  • Une classe ne doit pas combiner fonctions, méthodes, constantes avec des générations de sorties (echo, modifications fichiers, …)
  • Les namespaces doivent suivre les recommandations du PSR 4 Autoloader
  • Les noms des classes doivent être déclarées en PascalCase
  • Les noms des constantes doivent être déclarées en ALL_CAPS
  • Et les noms des méthodes doivent être déclarées en camelCase.

Ces règles sont indispensables pour avoir un code organisé et limiter les bugs lors d’utilisation de bibliothèques ou fonctions externes qui, elles, utiliseraient ce PSR.

PSR 3 Logger Interface “Un Logger en commun”

Le PSR 3 décrit une interface nommée Psr\Log\LoggerInterface permettant de mettre en place un système de Log. L’objectif est de pouvoir mettre en place un Logger commun à tous les projets PHP. Cette interface est adaptable aux CMS, framework et projets natifs. Elle permet de créer des logs en toute simplicité.

PSR 4 Autoloading Standard “Tous le même Namespace”

PSR 4 fonctionne en association avec PSR 0 qui est maintenant obsolète. Ensemble, ils définissent une manière commune d’écrire les chemins d’accès aux différents fichiers d’un projet afin de globaliser encore une fois les appels. Ils déterminent la règle permettant de décider quel dossier correspond à quel namespace et inversement. Ce PSR est interopérable (valide entre différents CMS, frameworks) et est parfaitement utilisable en association avec d’autres Autoloader

PSR 6 Caching Interface “Un Cache en commun”

Pour le PSR 6, le concept reste le même : uniformiser et globaliser différentes méthodes présentes en PHP. Ici il s’agit du CacheItemInterface qui est utilisé pour créer un système de cache. Ce qui est mis en place par beaucoup de développeurs pour améliorer notamment la vitesse de chargement d’une page. Il est identique au Logger dans son utilisation, il y a juste besoin de l’implémenter.

PSR 7 HTTP Message Interface “Un bon Message HTTP”

Beaucoup de projets utilisent le transfert d’information via HTTP pour lier leur application à un serveur. Ces données peuvent être envoyées sous forme de tableau, de Json, Xml, … Que ce soit pour l’envoi ou la réception ou la réception des données, la mise en place d’un HTTP Message contenant Header, Body est nécessaire : il permet la bonne compréhension lors des échanges de données.

Ici PSR propose deux interfaces permettant de gérer ces messages. Il s’agit de Psr\Http\Message\RequestInterface et de Psr\Http\Message\ResponseInterface pour respectivement l’envoi et la réception. Ces deux interfaces héritent de Psr\Http\Message\MessageInterface.
Elles permettent de générer des messages de manière simplifiée avec des méthodes qui vont impacter la totalité de la requête HTTP sans avoir besoin de la reprogrammer manuellement. Il y a également différentes interfaces recommandées tels qu’un système de Stream pour réduire la quantité de données envoyées dans certaines situations, ( exemple : UploadedFileInterface pour les envois de fichiers )

PSR 11 Container Interface “Appel à un Conteneur”

Le PSR 11 décrit une interface liée aux injections de conteneurs dans un projet. L'objectif de ce PSR est de globaliser la façon dont les frameworks et les bibliothèques utilisent un conteneur pour obtenir des objets et des paramètres.

Un conteneur est décomposé en deux parties : la configuration et la récupération des paramètres. L’utilisateur s’occupe généralement de la configuration.

La récupération des entrées pourra, quant à elle, être gérée par un framework dans le cas où il la prend en compte. Cela pose un problème au niveau de l'interopérabilité des frameworks : Prenons un exemple de projet sous Symfony, on programme la configuration selon les normes de Symfony, Laravel ne pourra donc pas lire cette configuration car il attend d’autres informations. Le ContainerInterface permet de faire face à ce problème en proposant une interface comprenant deux fonctions has() et get() pour vérifier et récupérer le paramètre désiré commun aux deux frameworks.

PSR 12 Extended Coding Style Guide “Rassemblons les standards avancés”

Extension du PSR 2 qui est maintenant obsolète, et du PSR 1 qui décrit les conventions de programmations basiques, le PSR 12 décrit tous les standards liés au code en PHP de manière étendue. Cela se compare à un guide sur comment coder de manière propre et uniforme en PHP. Il définit donc une liste exhaustive de critères et règles à respecter tels que le nombre de caractères par ligne, le type d’indentations, la déclaration des imports, le format des passages à la ligne entre fonctions et conditions, jusqu’à la présence ou non d’espaces dans l’initialisation des variables.

Il est juste nécessaire de connaître les formats et de les respecter pour qu’un code soit correctement évalué par la majorité des développeurs.

Il existe des outils permettant de vérifier le respect de cette règle comme les linters qui vérifient en temps réel et alertent le développeur.

Voir : https://www.php-fig.org/psr/psr-12/

Les liens hypertextes existent depuis très longtemps mais il n’existait pas de format commun pour les définir et les gérer. Ce PSR définit quatres interfaces permettant de regrouper les liens sous PHP. Parmi ces interfaces, il y en a deux permettant de créer un objet Link selon l’utilisation du lien dans le projet. La première avec un lien immuable et la seconde avec un lien évolutif.

Quant aux deux autres, elles permettent de faire une liste d’objets Link pour regrouper chaque lien selon leurs possibilités d’évolution ou non.

PSR 14 Event Dispatcher “Un système d’Events”

Ce PSR se constitue d’une compilation de règles concernant les éléments associés aux events (Listener, Dispatcher, …) et d’interfaces permettant leurs gestions. Le dépôt propose aux différents CMS et frameworks une gestion commune des Events et leur offre ainsi la possibilité d'interagir entre eux. Le package complet inclut la sécurité, le système de cache et de logs issus des autres PSRs.

PSR 15 HTTP Handlers “Un traitement commun des Réponses HTTP”

Le PSR 15 se rapporte à deux interfaces liées aux requêtes HTTP. Elles sont étroitement liées au PSR 7 sur les HTTP Message. A la sortie du PSR 7, chaque framework a créé son propre middleware pour utiliser ces HTTP Message. Cela a donc créé une différenciation entre les frameworks ce qui est contraire à l’objectif des PSRs.

PHP-Fig a donc mis en place MiddlewareInterface. Il s’agit d’une interface qui est accessible pour chaque framework et qui permet de supprimer les doublons présents dans leurs codes respectifs.

La même chose a été réalisée par le biais de la deuxième interface de ce PSR qui est RequestHandlerInterface. Les objectifs sont les mêmes : réduire la quantité de doublons et augmenter la possibilité de coopération entre les frameworks et CMS. Cette interface est utile lors des requêtes côté serveur, le requestHandler est la partie du code qui attend la réception de la requête HTTP et qui retourne une réponse associée. Ici, l’interface permet la mise en place de cette partie du code de manière simple, sécurisée et adaptable inter-framework.

PSR 16 Simple Cache “Un Cache plus simple”

Le PSR 16 est une extension du PSR 6 (Caching Interface). Ce PSR 6 comprend un système de cache complet permettant de répondre à tous les besoins, mais il est parfois trop volumineux pour certains projets souhaitant utiliser un système de cache basique.

Le Simple cache est une version simplifiée du PSR 6 notamment dans son contenu mais aussi dans son utilisation.

Il possède une interface permettant d’adapter ces deux PSRs : le CacheInterface qui offre la possibilité de stocker des données en cache simplement. Cette interface est bien sûr moins complète que le PSR 6, il faut donc choisir celui qui correspond le plus au besoin du projet.

PSR 17 HTTP Factories “Un générateur de HTTP”

Le PSR 7 implique l’utilisation d’interfaces pour les HTTP Message. Pourtant, dans certains projets déjà construits pré-PSR 7, l’intégration peut se révéler compliquée sans changer complètement le système HTTP.

Ce PSR 17 a pour but de faciliter l’accès au PSR 7. Il contient donc beaucoup de Factory concernant tous les types d’objets disponibles dans PSR 7 tels que RequestFactory, StreamFactory, UploadedFileFactory, …

Il n’y aura pas besoin de changer complètement le système HTTP mais uniquement de gérer l’intégration en se servant de ces Factory.

PSR 18 HTTP Client “Un gestionnaire de HTTP”

Pour ce PSR, il s’agit du même concept que le PSR 15 (HTTP Handlers). Cela consiste en l’utilisation du PSR 7 (HTTP Message) dans l’objectif de créer un Client commun permettant de gérer l’envoi de ces HTTP Message. Pour ce faire, PHP-Fig a créé ClientInterface. Il supprime la dépendance du site au HTTP Client et, par la même occasion, permet à ce HTTP Client de répondre aux critères de la méthode SOLID Substitution de Liskov (voir Coding Convention LINK).

Conclusion

Aucun de ces PSRs n’est obligatoire mais il est fortement recommandé de s’en servir afin d’optimiser sa manière de coder, de gagner du temps et surtout de faciliter la coopération entre diverses équipes de développement. Tous les frameworks et CMS ont pour objectif de mettre en place ces PSRs. S’il ne l’ont pas encore tous atteint, une grande partie est déjà opérationnelle et il est aujourd’hui aisé d’ajouter ces interfaces qui faciliteront grandement la vie des devs. Si vous souhaitez en savoir plus c’est par ici : https://www.php-fig.org/psr/

Poursuivez votre lecture sur ce(s) sujet(s) :