« Une classe ne devrait exposer en écriture que ce qu’elle veut bien laisser modifier de l’extérieur » — un principe de conception ancien, que PHP obligeait jusqu’ici à implémenter à coup d’accesseurs privés et de méthodes getXxx() écrites dans le seul but d’empêcher une modification externe. PHP 8.4, sorti en novembre 2024, referme enfin cet écart avec les propriétés à visibilité asymétrique.
Sur une classe de bloc complexe gérant l’état d’un configurateur de devis multi-étapes, ce mécanisme a permis de supprimer une douzaine de méthodes d’accès qui n’existaient que pour interdire une écriture externe non désirée — sans jamais ajouter la moindre logique métier.
Le problème que ce mécanisme résout
Avant PHP 8.4, protéger une propriété en écriture tout en la gardant lisible de l’extérieur imposait de la déclarer private et d’écrire un accesseur public dédié :
class ConfigurateurDevis {
private int $etapeCourante = 1;
public function getEtapeCourante(): int {
return $this->etapeCourante;
}
private function avancerEtape(): void {
$this->etapeCourante++;
}
}Cette méthode getEtapeCourante() ne fait strictement rien d’autre que retourner la valeur brute : elle existe uniquement pour contourner l’absence de granularité entre lecture et écriture dans la visibilité classique de PHP.
La syntaxe des propriétés à visibilité asymétrique
PHP 8.4 permet de déclarer une visibilité distincte pour la lecture et pour l’écriture d’une même propriété, avec le mot-clé private(set) ou protected(set) associé à une visibilité de lecture différente :
class ConfigurateurDevis {
public private(set) int $etapeCourante = 1;
public function avancerEtape(): void {
$this->etapeCourante++;
}
}
$configurateur = new ConfigurateurDevis();
echo $configurateur->etapeCourante; // lecture publique : autorisée
$configurateur->etapeCourante = 5; // écriture externe : erreur fatale
La propriété reste lisible publiquement, comme n’importe quelle propriété public classique, mais toute tentative d’écriture depuis l’extérieur de la classe déclenche une erreur, sans qu’aucun accesseur n’ait eu à être écrit pour l’empêcher.
Appliqué à une classe de bloc complexe
Sur un bloc de configurateur de devis à cinq étapes, plusieurs propriétés bénéficient directement de ce mécanisme : l’étape courante, le total calculé, et la liste des options sélectionnées ne doivent jamais être modifiées directement depuis le rendu du bloc, seulement à travers les méthodes métier dédiées :
final class ConfigurateurDevisBlock {
public private(set) int $etapeCourante = 1;
public private(set) float $totalEstime = 0.0;
public private(set) array $optionsChoisies = [];
public function selectionnerOption( string $optionId, float $prix ): void {
$this->optionsChoisies[ $optionId ] = $prix;
$this->totalEstime = array_sum( $this->optionsChoisies );
}
}Le rendu du bloc, dans render.php, peut désormais lire ces trois propriétés directement — $configurateur->totalEstime — sans passer par un accesseur, tout en conservant la certitude qu’aucun code externe ne peut altérer ce total autrement qu’en appelant selectionnerOption(), seule méthode habilitée à le recalculer.
Ce que ce mécanisme ne change pas
- Le typage de la propriété reste identique :
int,float,arrayou toute autre déclaration de type continuent de fonctionner exactement comme avant. - Les propriétés en lecture
privateouprotectedclassiques restent utilisables sans changement, la visibilité asymétrique n’étant qu’une option supplémentaire, pas un remplacement obligatoire. - Ce mécanisme ne remplace pas la validation métier : il empêche une écriture non désirée, pas une écriture invalide passée par la bonne méthode. Un contrôle de cohérence dans
selectionnerOption()reste nécessaire si besoin.
Une propriété
public private(set)documente, dans la signature même de la classe, l’intention du développeur — bien plus explicite qu’un accesseur qui pourrait, en théorie, cacher n’importe quelle logique.
Compatibilité et prérequis
Ce mécanisme n’existe qu’à partir de PHP 8.4, publié en novembre 2024 : un site hébergé sur une version antérieure de PHP ne peut pas en bénéficier, et une classe l’utilisant provoquerait une erreur de syntaxe fatale sur un environnement plus ancien. Avant de l’introduire dans un plugin ou un thème distribué publiquement, il convient de vérifier la version minimale de PHP annoncée dans son readme, faute de quoi une partie des utilisateurs se retrouverait avec un site en erreur au premier chargement.
En résumé
Les propriétés à visibilité asymétrique de PHP 8.4 suppriment une contorsion de conception ancienne : écrire un accesseur uniquement pour interdire une modification externe. Sur une classe de bloc à l’état interne riche, comme un configurateur de devis multi-étapes, ce mécanisme rend le code plus court et son intention plus lisible, sans rien changer à la logique métier elle-même.
