La semaine dernière, j’ai fait ma présentation au WordCamp Atlanta sur les espaces de noms et le chargement automatique. (le titre complet était Namespaces, Autoloading, and Improving Plugin Architecture mais c’est une bouchée, n’est-ce pas ?)

En raison de la nature de la discussion, j’ai choisi d’écrire un article pour accompagner la publication, de partager les diapositives et de partager un exemple de plugin GitHub pour aider à soutenir la discussion.

Alors si vous étiez présents, merci (!) et voici le post, promis. Et pour ceux d’entre vous qui n’y ont pas participé, j’espère que cet article aidera toujours à démontrer les concepts et les sujets dont j’ai discuté au WordCamp.

Espaces de noms et chargement automatique

Avant de parler des espaces de noms et du chargement automatique dans WordPress, la raison pour laquelle je veux en parler est que cela peut avoir un impact direct sur la qualité de votre code et cela peut le faire pendant des mois et des années à venir.

Après tout, beaucoup d’entre nous, développeurs, ne se posent-ils pas déjà la question :

Comment rendre notre code meilleur qu’il ne l’est déjà ?

Et beaucoup d’entre nous sont assez intelligents pour savoir ce que nous ne savons pas. Nous sommes donc confrontés à travailler dans le cadre des contraintes qui nous sont données.

Parfois, nous avons le temps d’étudier les moyens de le faire ; d’autres fois, nous avons du travail avec les connaissances que nous avons. Et il n’y a rien de mal à cela.

Mais parce que nous savons ce que nous ne savons pas, nous savons qu’il y a du potentiel pour plus.

Tout d’abord, votre code

Quand il s’agit de parler de sujets comme les espaces de noms et le chargement automatique dans le contexte de WordPress, je pense que nous rencontrons souvent des réponses mitigées.

Après tout, nous pourrions parler de choses comme The Theme Customizer ou l’ API REST ou quelque chose de plus amusant.

Je veux dire, "les espaces de noms et le chargement automatique" ne semblent tout simplement pas excitants ou avancés par rapport aux nouvelles fonctionnalités et technologies disponibles, n’est-ce pas ?

Mais non, ils ne sont pas vraiment ennuyeux. Et à travers cet article et la présentation et le code source qui l’accompagnent, je vais vous montrer pourquoi et comment ils ne le sont pas.

Ils ne sont pas ennuyeux

Je pense qu’il est juste de dire que les développeurs – au moins une partie d’entre nous ou une partie d’entre eux selon la façon dont vous vous voyez – sont connus pour discuter des aspects de la programmation.

"Conversation ennuyeuse de toute façon."

En fait, il n’est pas du tout rare d’entendre quelqu’un discuter de la meilleure façon d’initialiser et d’écrire une boucle for aussi performante que possible lors de l’itération sur un petit ensemble de base de données malgré le fait que nous ayons des processeurs quadricœurs et 16 Go de RAM. dans nos machines de bureau.

Donc, si nous nous soucions autant de quelque chose d’aussi petit, nous nous soucions sûrement de l’image plus grande. Des choses telles que :

Code amélioré
Meilleure organisation
Maintenabilité accrue
Débogage plus facile
Gagner plus d’argent (enfin, peut-être).

Et les espaces de noms et le chargement automatique peuvent mener directement à tout ce qui précède (enfin, je ne peux pas parler d’argent, mais cela a du potentiel).

Si je devais résumer les espaces de noms de rôle et le lieu de chargement automatique dans tout ce qui précède, je dirais que :

Les espaces de noms et le chargement automatique conduisent à un code amélioré grâce à une meilleure organisation, compartimentation ou modularisation, et à une relation plus étroite grâce à leurs concepts.

De plus, cela augmente la maintenabilité car le code est organisé en packages, ce qui peut faciliter le débogage à mesure que le produit se développe.

Tout cela peut entraîner un gain de temps ou une meilleure utilisation du temps, ce qui, selon votre modèle d’entreprise, peut avoir un impact sur vos résultats.

Mais cela ne décrit toujours aucune de ces choses. Mais sûrement, à ce stade, ils semblent plus intéressants que lorsqu’ils ont été introduits pour la première fois.

Alors, qu’est-ce qu’ils sont?

Avant d’entrer dans les définitions de chacun et des rôles qu’ils jouent, examinons comment le manque d’espaces de noms et de chargement automatique dans WordPress a eu un impact négatif sur votre expérience lors de l’utilisation de thèmes, de plugins, de modules complémentaires ou de tout ce que vous avez.

Revenons un instant en arrière et regardons chacun individuellement.

Espaces de noms

Imaginez que vous avez hérité d’un projet et que vous êtes sur le point de commencer à travailler dessus. Dites que c’est un plugin WordPress.

Vous l’installez ; vous allez l’activer et vous recevez au moins l’un de ces éléments :

Peut-être voyez-vous ce message d’organisation désagréable en haut de la fenêtre du navigateur affichant une trace de pile.
Peut-être voyez-vous un message indiquant un conflit avec un autre package existant.
Ou peut-être que lorsque vous essayez d’activer un plugin, la page s’actualise mais le plugin ne s’active pas.
Peut-être avez-vous même effectué un audit de code et voyez-vous des vérifications class_exists dans toute la base de code.

Tout ou partie de ce qui précède peut contribuer à des problèmes, bien sûr, avec les projets WordPress. Mais les espaces de noms peuvent vraiment résoudre une grande partie de cela la plupart du temps.

Autrement dit, la raison pour laquelle vous rencontrez ces problèmes est que le code avec lequel vous travaillez fait partie de l’espace de noms global (par rapport à son espace de noms) et PHP n’aime pas quand il y a des classes et des modules nommés la même chose .

Mais lorsque vous nommez quelque chose, vous lui donnez sa zone relative à lui-même qui fonctionnera toujours bien avec d’autres composants même s’ils ont le même nom de classe.

Chargeurs automatiques

En ce qui concerne les chargeurs automatiques, ils sont un peu moins compliqués à certains égards. Pensez d’abord au code que vous écrivez ou au code avec lequel vous travaillez – en particulier dans le contexte des plugins WordPress – puis réfléchissez au nombre de fois que vous écrivez ou voyez ce qui suit :

comprendre
inclure_une fois
exiger
Demandez une fois

Et parfois, vous les voyez en haut du fichier qui démarre le plugin, et parfois vous les voyez dispersés dans la base de code.

S’ils sont tous contenus dans un seul fichier, ce n’est pas aussi grave car au moins vous savez où ils se trouvent. Mais s’ils sont jonchés partout, alors vous n’avez aucune idée d’où une dépendance est introduite dans le système.

Le chargement automatique peut résoudre tout cela en chargeant les dépendances en cas de besoin (et pour ceux qui sont intéressés, le chargement automatique est plus rapide que l’inclusion manuelle).

Espaces de noms

Cela dit, nous sommes prêts à parler à la fois des espaces de noms et du chargement automatique. Mais les espaces de noms sont le concept fondamental, nous allons donc commencer par là.

Mais après tout ce qui précède, vous pouvez voir les avantages de leur utilisation. Peut-être même qu’ils sont amusants, n’est-ce pas ? Peut-être?

Quoi qu’il en soit, nous avons besoin d’une définition à partir de laquelle nous pouvons travailler lorsque nous en parlons pour le reste de l’article.

Le manuel PHP fournit la définition suivante :

Les espaces de noms sont conçus pour résoudre deux problèmes rencontrés par les auteurs de bibliothèques et d’applications lors de la création d’éléments de code réutilisables tels que des classes ou des fonctions…

Et ce n’est pas mal, mais c’est assez long, technique, et c’est peut-être un peu trop pour ceux qui débutent. Alors simplifions un peu pour cet article :

Un peu mieux, peut-être ?

Un moyen de regrouper des classes et des interfaces liées ayant un objectif similaire.

Je ne vais pas parler d’interfaces dans cet exposé ; cependant, je sais qu’il existe des développeurs orientés objet de niveau intermédiaire qui les utilisent, donc je voulais m’assurer de les mentionner au moins.

Un exemple pratique

Je n’aime pas les exemples de programmation qui ne donnent pas d’applications réelles ou pratiques. Souvent, on nous donne des exemples de choses que nous ne codifierions jamais.

Combien de fois avez-vous lu un article orienté objet et il donne un exemple d’une classe d’animaux ou d’une classe de voitures ? Nous n’allons pas programmer une voiture.

Nous sommes beaucoup plus susceptibles de travailler avec des fichiers. Nous allons donc nous intéresser à un ensemble de classes chargées de lire et d’écrire des fichiers. C’est-à-dire que nous avons été de bons programmeurs orientés objet et avons séparé nos classes en fonction des responsabilités qu’elles assument.

Et oui, vous pouvez avoir des interfaces ; cependant, ils sortent du cadre de cet article, ils ne seront donc pas inclus.

Donc, pour notre FileReader, peut-être que les bases de la classe ressemblent à ceci :

Une classe pour lire des fichiers.

Notez que la fonction accepte le nom du fichier qu’elle doit ouvrir en lecture. La vérification des erreurs, la façon dont il lit le fichier et ce qu’il renvoie dépendent de l’implémentation de la classe.

Et pour le FileWriter, nous avons quelque chose comme ça :

Une classe pour écrire des fichiers.

Cette classe, en revanche, accepte les informations qu’elle va écrire sur le disque et le nom du fichier dans lequel elles doivent être écrites.

Encore une fois, comme dans l’exemple ci-dessus, cela n’inclut pas la vérification des erreurs, l’écriture via une ressource, la fermeture des ressources, etc.

Mais il ne s’agit pas de travailler avec des fichiers. Au lieu de cela, il s’agit de montrer comment espacer les noms de votre code, et ces deux exemples sont censés être fondamentaux pour cela.

Remarques sur les espaces de noms

Il y a une mise en garde à ce que vous voyez dans les images de l’exemple de code ci-dessus : ces classes ne sont pas dotées d’un espace de noms. C’est-à-dire qu’ils résident dans l’espace de noms global, ce qui les laisse mûrs pour des conflits avec d’autres classes.

Regardez-le de cette façon : imaginez que vous empaquetez ce code dans un plugin pour quelqu’un d’autre, puis qu’il charge un autre plugin qui a également un FileReader ou un FileWriter. Comme tout va faire partie du même espace de noms global, vous allez être confronté à un conflit.

Rappelles toi:

Les espaces de noms sont un moyen de regrouper des classes et des interfaces liées ayant un objectif similaire.

Prenons donc les classes et namespace le code.

Tout d’abord, nous fournirons un espace de noms de niveau supérieur sous lequel ces classes et toutes les autres classes résideront ; puis nous fournirons un sous-paquet (ou un sous-espace de noms ou un sous-espace comme je les ai entendus appeler) dans lequel ces classes de fichiers résideront.

Cela signifie que notre FileReader ressemblera désormais à ceci :

Une classe avec espace de noms pour lire des fichiers.

Et notre FileWriter ressemblera maintenant à ceci :

Une classe avec espace de noms pour écrire des fichiers.

Tout d’abord, vous pouvez voir que l’utilisation des espaces de noms est facile : vous utilisez simplement le mot-clé namespace, puis déclarez l’espace de noms (qui pourrait tout aussi bien être WCATL) en haut avec les sous-paquetages suivants.

Mais cela conduit à d’autres sujets – à savoir autour de l’organisation des fichiers, de l’instanciation et du chargement automatique – qui méritent tous d’être couverts.

Sur l’organisation du dossier

À ce stade, il est important d’avoir un mot sur l’organisation des fichiers. En fonction de la personne à qui vous parlez, vous constaterez que certains développeurs – surprise, surprise – ont une opinion sur la manière dont les fichiers doivent être organisés (et je ne suis pas différent).

D’une part, vous n’avez pas du tout à organiser vos fichiers. En fait, vous pouvez tout déposer dans le répertoire racine de votre projet, espacer les informations et être prêt à partir.

Fichiers non organisés

L’ensemble de fichiers ci-dessus est destiné à un petit projet, vous pouvez donc imaginer combien de fichiers existeraient pour un grand projet.

Mais lorsque vos fichiers sont organisés de cette manière, cela peut rendre l’écriture d’un chargeur automatique un peu difficile, car un chargeur automatique doit savoir où trouver les fichiers en fonction de leur espace de noms.

C’est là qu’interviennent les termes «organisation logique» et «organisation virtuelle ».

L’organisation logique fait référence à la façon dont les fichiers sont organisés sur le disque, comme ce que vous voyez ci-dessus. Ils sont logiquement situés dans le répertoire racine.
L’organisation virtuelle fait référence à la façon dont les fichiers sont organisés en fonction de leurs espaces de noms. Cela signifie qu’il existe des répertoires et des sous-répertoires qui correspondent aux espaces de noms, aux sous-packages, etc.

Donc, si vous deviez prendre le projet ci-dessus, ses espaces de noms, ses sous-paquetages, puis les organiser à la fois logiquement et virtuellement, cela ressemblerait à ceci :

Espaces de noms et chargement automatique : fichiers organisés

Et bien que vous puissiez choisir d’organiser vos fichiers comme bon vous semble, je suis partisan de m’assurer qu’il y a une parité entre les deux. Autrement dit, j’aime que mon organisation logique et mon organisation virtuelle correspondent comme vous le voyez dans l’image ci-dessus.

Au fur et à mesure que j’aborderai la question du chargement automatique, vous comprendrez pourquoi cela est important.

Remarques sur les espaces de noms

Que se passe-t-il, cependant, lorsque nous devons instancier des classes qui ont un espace de noms ? Lorsque les classes n’ont pas d’espace de noms, il est facile d’utiliser le mot-clé ‘new’.

Instanciation sans espace de noms.

Mais nous devons instancier une classe namespaced, nous devons aller plus loin et utiliser le nom complet :

Espaces de noms et chargement automatique : instanciation avec un espace de noms.

Mais cela devient fastidieux, n’est-ce pas? Cet exemple particulier n’est pas si mal, mais imaginez si vous travailliez sur quelque chose avec plus de sous-paquetages. Cela deviendrait assez lourd, n’est-ce pas ?

À cette fin, nous pouvons utiliser ce qu’on appelle l’aliasing. C’est simple aussi. Nous pouvons définir utiliser le mot-clé ‘use’ en haut du fichier pour faire référence à l’espace de noms que nous voulons alias, puis utiliser le dernier sous-paquet dans le cadre de l’alias pour instancier notre classe.

Cela semble déroutant, n’est-ce pas? Peut-être que le voir en action aidera:

Espaces de noms d’alias.

Et c’est tout ce qu’il y a à faire. Oui, vous pouvez aller plus loin dans l’aliasing, mais c’est tout ce que je vais faire dans le contexte de cet article.

Chargement automatique

À ce stade, nous avons posé les bases du chargement automatique. Oui, travailler avec des espaces de noms peut représenter beaucoup de travail si vous n’y êtes pas habitué ; cependant, il est important de comprendre car le chargement automatique nécessite un peu de travail qui peut être inattendu si vous ne l’avez jamais découvert auparavant.

Quoi qu’il en soit, les choses les plus importantes à retenir concernant les espaces de noms, à ce stade, sont :

Les espaces de noms sont un moyen de regrouper des classes et des interfaces liées ayant un objectif similaire.
Créez la parité à travers vos fichiers et espaces de noms en vous assurant que votre organisation logique et virtuelle sont les mêmes.

Et maintenant, il est temps de se pencher sur le chargement automatique.

Remarques sur le chargement automatique

Voyons d’abord la définition du chargement automatique telle qu’elle est fournie par le manuel PHP :

La fonction spl_autoload_register() enregistre n’importe quel nombre de chargeurs automatiques, permettant aux classes et aux interfaces d’être automatiquement chargées si elles ne sont actuellement pas définies. En enregistrant les chargeurs automatiques, PHP a une dernière chance de charger la classe ou l’interface avant qu’elle n’échoue avec une erreur.

Ce n’est pas mauvais. C’est long quand même. Donc, tout comme nous l’avons fait avec les espaces de noms, utilisons une définition plus courte pour cet article :

Un moyen de charger automatiquement des interfaces et des classes sans utiliser les instructions include et require.

Encore une fois, nous n’utiliserons pas d’interfaces dans cet article, bien que certains développeurs le fassent. Et cela fournira la définition de travail pour le reste de cet article.

Un exemple pratique

Une fois que vous avez organisé vos fichiers, leur espace de noms et qu’ils sont prêts à être chargés, il est temps de le faire, n’est-ce pas ? Je veux dire:

vos fichiers sont organisés,
vous êtes prêt à les charger

Il est donc temps de le faire automatiquement, n’est-ce pas ? Mais il y a un hic. L’ensemble des fichiers "à chargement automatique" nécessite un peu de travail.

Écrire un chargeur automatique

C’est-à-dire que c’est automatique, mais cela demande encore un peu plus de travail de notre part. Avant d’entrer dans ces étapes, il est important de noter :

ce n’est pas entièrement automatisé,
nous devons l’écrire.

Aussi agréable que ce soit d’avoir le code chargé automatiquement, nous devons lire certaines données, les analyser, puis essayer de charger le bon fichier.

Mais en supposant que vous l’écriviez correctement et que votre espace de noms et organisez vos fichiers de la même manière pour chaque projet, vous pouvez réutiliser votre chargeur automatique. Autrement dit, vous l’écrivez une fois et vous pouvez l’utiliser dans d’autres projets.

Étapes pour un chargeur automatique

Lors de l’écriture d’un chargeur automatique, il n’y a que quelques étapes à suivre. L’autochargeur doit pouvoir répondre aux fichiers suivants :

Où sont les fichiers ?
Comment sont-ils nommés ?
Le fichier existe-t-il ?

Si tout ce qui précède est vrai (ou si vous pouvez répondre "oui" à tous), alors l’autochargeur fera ce qu’il est censé faire.

Nous allons jeter un œil à du code dans un instant, mais la première chose à noter est qu’il utilise une fonction appelée spl_autoload_register.

SPL fait référence à la bibliothèque PHP standard, et la fonction accepte une fonction comme argument, et cette fonction accepte le nom de la classe qui va être instanciée. C’est plus procédural qu’orienté objet, et j’en parlerai dans un instant, mais il est important de garder à l’esprit que vous lisez ce code.

Voici la première partie du code. Je vais vous expliquer ce qu’il fait après coup:

Chargement automatique, partie 1 – Trouver la classe

Dans cette partie du code, la fonction reçoit le nom complet de la classe à instancier (comme "WCATLFileFileReader()").

Ensuite, il sépare toutes les parties du nom complet en parties. Le nom de la classe est le dernier index du tableau, et j’opte pour nommer mes fichiers comme "class-filereader.php" afin que la fonction crée une variable, $class_file, qui fait référence au nom du fichier.

Mais nous n’avons pas encore fini. Nous devons encore obtenir le nom complet (c’est-à-dire l’emplacement du fichier sur le disque). Cela pourrait ressembler à ceci :

Chargement automatique, partie 2 – Obtenir le nom complet

À ce stade, nous préparons une variable, $full_qualified_path, qui fera référence au répertoire de niveau supérieur.

Ensuite, le code parcourt tous les index du tableau et crée un chemin pour le fichier de classe. Vous pouvez imaginer cela comme la construction d’une chaîne telle que "wcatlfile" que nous combinons ensuite avec le $class_file.

Cela signifie que le chemin d’accès complet au fichier devient "wcatlfileclass-filereader.php".

Et enfin, nous incluons le fichier. Notez que ce code ne vérifie pas si le fichier existe. Bien que je le recommande, il a été omis pour des raisons de longueur et parce que, dans notre exemple, nous savons que le fichier existe.

Si le fichier n’existe pas, plusieurs options s’offrent à vous :

Lancer une exception,
Attraper une exception,
Affichez votre propre message d’erreur,
Ou une autre option que je pourrais envisager dans cet article.

Quoi qu’il en soit, l’idée est d’être défensif dans votre code afin que vous puissiez vous préparer au cas où un fichier n’existe pas et que vous puissiez gérer l’échec avec élégance.

Sur le chargement automatique

Avant de conclure, il est important de noter ce qui suit :

Tout au long de l’exemple, nous avons utilisé du code orienté objet lors de l’espacement des noms du code. Après tout, c’est un concept orienté objet.
Notre chargeur automatique est écrit en code procédural. Ce qui donne?

En fin de compte, cela a à voir avec la bibliothèque PHP standard. Vous pouvez écrire un chargeur automatique orienté objet, mais je pense que c’est un peu exagéré dans de nombreux cas.

Le processus de chargement d’un fichier est un processus étape par étape, il est donc naturel de l’écrire de manière procédurale.

Enfin, d’autres peuvent choisir d’utiliser des outils tels que Composer pour apporter des dépendances. Ce sont d’excellents outils, et il y a beaucoup d’avantages à utiliser quelque chose comme ça ; cependant, cela dépasse les concepts et les sujets de cet article et il vaut mieux le laisser pour une future discussion.

Ressources (et merci !)

Cela a été l’un des articles les plus longs que j’ai écrits pour mon site.

C’est en partie parce qu’il est basé sur une conférence pour un WordCamp et aussi parce que je veux m’assurer que je fournis une introduction et une base solides où vous pouvez commencer à incorporer des espaces de noms et à charger automatiquement dans vos plugins WordPress.

En plus de cet article, j’ai également fourni les ressources suivantes :

Les slides de ma présentation sont disponibles sur SpeakerDeck.
J’ai le code de cette présentation disponible en téléchargement sur GitHub.

Et avec cela, j’espère que cela fournit une introduction solide aux espaces de noms et au chargement automatique et que vous pourrez commencer à incorporer cela de plus en plus dans votre travail. Cela profite grandement à votre travail et aux autres développeurs qui pourraient également utiliser votre travail.

Source d’enregistrement: tommcfarlin.com