PHP 8 Objects, Patterns and Practice

1Les objets étaient une réflexion après coup, et ça explique beaucoup

« Beaucoup de projets PHP naissent petits et évoluent en monstres » (p. 3). Pour comprendre pourquoi, Zandstra raconte l'histoire du langage : les objets ont « un jour été décrits comme une réflexion après coup par les concepteurs de PHP » (p. 13). PHP 4 copiait les objets en silence à l'assignation : une génération de bugs sans message d'erreur. PHP 5 a réparé le modèle, PHP 7 l'a typé, PHP 8 l'a poli (constructeurs promus, arguments nommés, attributs). Le PHP moderne est méconnaissable, et c'est précisément pour ça qu'il fallait un livre qui fasse le pont entre le passé du langage et son présent.

2« J'avais surprivilégié l'héritage » : l'aveu qui ouvre les patterns

La partie patterns s'ouvre sur une confession : « j'ai découvert que j'avais surprivilégié l'héritage dans mes designs, en essayant de construire trop de fonctionnalités dans mes classes » (p. 254). Son exemple fil rouge : une classe Lesson avec deux axes de variation, le type de cours (magistral, séminaire) et la tarification (fixe, horaire). L'héritage force à multiplier les combinaisons ; chaque nouvel axe double l'arbre. La composition branche la tarification comme une pièce :

// ✗ une sous-classe par combinaison : ça double à chaque nouvel axe
CoursMagistralFixe, CoursMagistralHoraire, SeminaireFixe, SeminaireHoraire…

// ✓ la tarification est une pièce branchée (le vrai design du livre)
class Lesson {
    public function __construct(private CostStrategy $costStrategy) {}
    public function cost(): int {
        return $this->costStrategy->cost($this);  // délégation
    }
}

On échange TimedCostStrategy contre FixedCostStrategy à l'exécution, sans reconstruire d'arbre. Le principe GoF derrière, cité par le livre : « encapsulez le concept qui varie » (p. 269).

3La magie a des coûts cachés

PHP permet de tout intercepter : __get, __set, __call attrapent les accès à des propriétés et méthodes qui n'existent pas. Les frameworks s'en régalent. L'avertissement de Zandstra mérite d'être encadré : « la magie est arbitraire et inattendue. La magie plie les règles. La magie a des coûts cachés » (p. 136). Un objet plein de méthodes magiques ment à votre éditeur, à l'analyse statique, et au prochain lecteur. Même vigilance pour __clone : PHP copie les objets en surface, et un clone partage ses propriétés-objets avec l'original tant qu'on ne les clone pas à la main.

4Les quatre odeurs d'un design qui tourne mal

Le chapitre 6 est le cœur conceptuel de la partie Objects. Quatre signaux qu'un design réclame une reprise :

• La duplication de code. La même routine éparpillée à plusieurs endroits : un changement oblige à toutes les retrouver.
• La classe qui en savait trop. Une classe qui regarde des globales et des contextes au-delà du sien : elle ne peut ni voyager, ni être testée seule.
• L'homme à tout faire. Une classe qui fait tout : chaque nouveau besoin la fait grossir elle, au lieu de faire grandir le système.
• Les conditionnels répétés. Le même if/switch qui revient dans plusieurs méthodes : c'est une hiérarchie de types qui demande à exister. Le polymorphisme ne supprime pas le conditionnel, il le centralise en un seul endroit.

5Sa position contrariante : Service Locator d'abord

Là où la littérature moderne traite l'injection de dépendances comme un dogme, Zandstra la pèse en ingénieur. Le Singleton ? Dangereux si on en abuse, mais « je pense qu'un usage modéré du pattern Singleton peut améliorer le design d'un système » (p. 284), à déployer « avec parcimonie et précaution ». Les conteneurs d'injection complets ? « L'injection de dépendances offre la pureté, mais elle exige une autre forme d'adhésion : il faut croire à la magie de l'assembleur » (p. 329). Son choix à lui : « je préfère partir de la solution la plus simple et refactorer vers plus de complexité si besoin. Pour cette raison, j'opte généralement pour Service Locator » (p. 329). Pas obligé d'être d'accord ; un livre qui argumente au lieu de réciter vaut plus cher.

6L'anatomie de Doctrine, reconstruite à la main

Le chapitre 13 construit, pièce par pièce, ce que tout ORM PHP cache sous le capot. Le Data Mapper : une classe dont le seul métier est de faire circuler les données entre objets et tables, « la grande force de ce pattern est le fort découplage qu'il opère entre la couche domaine et la base de données » (p. 513). L'Identity Map : un registre qui garantit un seul objet par ligne de base, pas de double chargement. L'Unit of Work : le carnet qui note ce qui est neuf, modifié ou supprimé, et écrit tout à la fin. Le Lazy Load : la collection qui n'interroge la base qu'au premier accès. Lisez ce chapitre puis ouvrez les sources de Doctrine : vous reconnaîtrez chaque organe par son nom.

7Un mini-framework nommé woo, pour prouver qu'il n'y a pas de magie

Le chapitre 12 assemble les patterns d'entreprise en un petit framework que le livre appelle woo : un Front Controller qui reçoit toutes les requêtes, des commandes qui les interprètent (« les commandes sont une sorte de gare de triage », p. 443), un Application Controller qui choisit la vue suivante, un Domain Model qui ignore tout de la base. C'est un squelette de Symfony en miniature, construit sous vos yeux. Et Zandstra est honnête sur le prix : cette architecture « n'est pas pour les âmes sensibles : elle exige beaucoup de développement initial avant d'en voir les bénéfices » (p. 449). C'est exactement la raison d'être des frameworks : payer ce prix une fois, pour tout le monde.

8Le développement ne s'arrête pas au code

La troisième partie est une prise de position : savoir concevoir ne suffit pas, il faut l'écosystème qui rend la livraison répétable. « Le développement ne s'arrête pas au code » (ch. 14). Composer et le versionnage sémantique, Git, PHPUnit et les mocks, les standards (PSR-1, PSR-12, PSR-4), l'intégration continue. Les outils choisis en 2021 ont vieilli inégalement (Vagrant et Phing ont perdu face à Docker et GitHub Actions, Jenkins survit en entreprise), mais la thèse, elle, n'a pas pris une ride : un développeur qui maîtrise les objets et les patterns mais ne sait ni tester ni versionner n'est qu'à moitié développeur.