mageekblog

Suite à mon billet sur l'intérêt des tests unitaires sur les méthodes privées ou protégées, j'ai eu beaucoup de commentaires au sujet de l'encapsulation et sur sa mise en œuvre.

Récemment, cousin @ub sans bermuda, l'un de mes collègues chez PMSIpilot,  a relancé le débat via un sondage, même si son objectif était plutôt de lancer un débat sur le thème la composition contre l'héritage.

J'ai donc décidé de prendre mon clavier pour à la fois essayer de répondre à ces interrogations et mettre à plat ma propre réflexion sur le sujet.

L'encapsulation, dans le cadre de la POO, consiste dans le fait de masquer à l'utilisateur d'une classe les détails de son implémentation.

En PHP, elle est mise en œuvre à l'aide des mots-clefs private, protected et public, qui sont applicables au choix sur les propriétés d'une classe ou ses méthodes.

Le mot-clef private permet donc très logiquement de masquer à l'utilisateur final les propriétés et les méthodes sur lesquelles il est appliqué, alors que public, à contrario, permet de rendre les éléments sur lesquels il est appliqué totalement accessibles.

Enfin, tout ce qui est protected a un statut particulier, dans le sens ou tout ce sur quoi il est appliqué se comporte comme étant privé pour l'utilisateur de la classe, et comme étant publique dans les classes dérivées.

Lors de la conception d'une classe, le développeur doit donc choisir entre ces différents niveaux de visibilité, et cela à bon escient, car un mauvais choix à ce niveau peut avoir des répercussions parfois très gênantes pour les utilisateurs.

Or, il n'y a aucune règle explicite gouvernant l'utilisation de ces mots-clefs, car elle dépend très étroitement du contexte.

Dans le cadre de mon travail, je viens d'être confronté à une problématique intéressante, dans le sens où elle m'a fait utiliser une fonctionnalité de PHP 5.3 que je n'avais encore jamais eu l'occasion d'utiliser, à savoir intl.

J'ai été en effet obligé de trouver un code PHP permettant de transformer la chaîne de caractères Équipe médicale principale en equipeMedicalePrincipale.

Le problème peut sembler trivial, et pourtant, il n'est pas simple à régler.

Il est possible de le décomposer en quatre étapes :

1. Passage en casse basse de la première lettre.
2. Suppression des accents.
3. Passage en casse haute de toutes les lettres précédées d'un espace.
4. Suppression des espaces blancs.

Et si les étapes 1, 3 et 4 sont relativement simple, l'étape 2 est quand à elle beaucoup plus délicate à solutionner.

Lors du forum PHP 2010, j'ai eu l'occasion de discuter avec Rasmus Lerdorf, Ilia Alshanetsky et Derick Rethans.

Il est ressorti de ces discussions un article au sujet de PHP, de son avenir et de sa communauté, destiné à paraître dans Programmez!, mais qui n'a apparemment pas été retenu.

Je vous en propose donc ici une version légèrement remaniée, afin que le temps que j'ai passé à l'écrire durant le forum au lieu d'assister aux conférences qui m'intéressaient ne soit pas entièrement perdu.

Je précise que cet article a été écrit il y a plus d'un mois, au moment du forum, et que depuis, l'actualité du langage a beaucoup évoluée.

En conséquence, les informations qu'il contient ne sont plus d'actualité pour certaines, et je vous invite donc à lire les billets relatifs à l'évolution du développement afin de faire le tri.

Avec un peu de retard à cause d'un emploi du temps relativement chargé actuellement, voici ma chronique habituelle concernant le développement de PHP.

Après l'effervescence de la période précédente causée par le vent de révolution qui a soufllé dans le monde des développeurs du langage, les dix jours qui viennent de s'écouler ont été plus calmes.

Cependant, cela ne veut pas dire qu'ils ont été dénués d'intêrets.

En effet, si les modifications apportées au trunk sont quasiment exclusivement des corrections et des optimisations issues du travail effectué sur les branches 5.2 et 5.3, la liste de diffusion des contributeurs est restée active.

Une nouvelle RFC a été proposée, et les débats commencés durant les dix jours précédents ont continué.

De plus, de nouveaux débats ont commencé, et certains ont déclenché une vive discussion.

Je <ironie>m'amuse</ironie> énormément avec PHPUnit actuellement, dans le cadre de mon travail.

Évidemment, j'ai rencontré quelques problèmes, mais rien de bien insurmontable, jusqu'à il y a quelques jour ou je me suis rendu compte que le rapport de couverture de code n'était plus généré.

Après quelques recherche, j'ai découvert que le problème provenait d'un appel à require('php://temp') dans le cadre d'une méthode de test.

Cependant, à partir de cette information, j'ai eu du mal à incriminer avec certitude PHPUnit, puisque ce dernier fait appel à un outil externe, à savoir Xdebug, pour collecter les informations relatives à la couverture de code.

Je me plonge donc actuellement dans les arcanes de PHPUnit et de Xdebug afin de découvrir le coupable, et du coup, je suis obligé de lire dans le détail leur documentation.

Or, celle de Xdebug est parfois incomplète sur certain point précis, comme, par exemple, la couverture de code (merci Murphy).

Le développement de PHP vit depuis la dernière rétrospective une période mouvementée.

En effet, il y a actuellement deux nouvelles versions du langage en préparation, et une troisième, qui correspond à la version de développement et devrait en théorie s'appeler PHP 5.4, est en cours de préparation.

De plus, il souffle sur la liste de diffusion des contributeurs, internals@, comme un léger vent de révolution.

En effet, si vous ne le saviez pas encore, en caricaturant quelque peu, il y a actuellement trois camps au sein de la communauté des contributeurs au langage, qui se livre quasiment quotidiennement un combat acharné pour parvenir à leurs fins.

L'un, que j'appellerai le camp traditionaliste, fait tout pour que le développement de PHP se poursuive de la même façon que depuis toujours, à savoir avec peu, voir aucun, formalisme, un pragmatisme forcené qui frise parfois le ridicule, une mauvaise fois récurrente et un nombrilisme relativement prononcé qui lui fait perdre de vue, voir même totalement ignorer, les désirs des utilisateurs.

L'autre, que j'appelais le camp progressiste, fait au contraire tout ce qu'il peut pour faire évoluer le développement du langage vers plus de formalisme tout en l'ouvrant plus largement vers les utilisateurs, en écoutant ce qui vient de l'extérieur en essayant d'en tirer le meilleur.

Et entre les deux, il y a les éternels indécis qui font parti de ce que j'appellerais le camp centriste et dont l'opinion varie au grès des courants et des pressions appliquées par l'un ou l'autre camp.

Et depuis quelques jours, le camp progressiste a lancé une grande offensive sur plusieurs points, en proposant plusieurs RFC qui vont pour la plupart à l'encontre des idées du camp traditionaliste.

En conséquence, si le trunk, qui contient la version en cours de développement de PHP, a évolué et que quelques modifications significatives ont été effectuées ces dix derniers jours, les choses les plus intéressantes se sont produites sur internals@.