PHP 8 Objects, Patterns and Practice

1Objects were an afterthought, and that explains a lot

"Many PHP projects start their life small and evolve into monsters" (p. 3). To understand why, Zandstra tells the language's story: objects were "once described as an afterthought by PHP's designers" (p. 13). PHP 4 silently copied objects on assignment, a generation of bugs without an error message. PHP 5 fixed the model, PHP 7 typed it, PHP 8 polished it (promoted constructors, named arguments, attributes). Modern PHP is unrecognizable, and that's precisely why a book had to bridge the language's past and its present.

2"I had overprivileged inheritance": the confession that opens the patterns

The patterns section opens on a confession: "I found that I had overprivileged inheritance in my designs, trying to build too much functionality into my classes" (p. 254). His running example: a Lesson class with two axes of variation, the lesson type (lecture, seminar) and the pricing (fixed, hourly). Inheritance forces you to multiply the combinations; every new axis doubles the tree. Composition plugs the pricing in as a part:

// ✗ one subclass per combination: it doubles with every new axis
LectureFixed, LectureTimed, SeminarFixed, SeminarTimed…

// ✓ pricing is a plugged-in part (the book's actual design)
class Lesson {
    public function __construct(private CostStrategy $costStrategy) {}
    public function cost(): int {
        return $this->costStrategy->cost($this);  // delegation
    }
}

Swap TimedCostStrategy for FixedCostStrategy at runtime, no tree to rebuild. The GoF principle behind it, quoted by the book: "encapsulate the concept that varies" (p. 269).

3Magic has hidden costs

PHP lets you intercept everything: __get, __set, __call catch access to properties and methods that don't exist. Frameworks feast on it. Zandstra's warning deserves to be framed: "Magic is arbitrary and unexpected. Magic bends the rules. Magic incurs hidden costs" (p. 136). An object full of magic methods lies to your editor, to static analysis, and to the next reader. Same vigilance for __clone: PHP copies objects shallowly, and a clone shares its object properties with the original until you clone them by hand.

4The four smells of a design gone wrong

Chapter 6 is the conceptual heart of the Objects part. Four signals that a design needs rework:

• Code duplication. The same routine scattered in several places: one change means hunting them all down.
• The class who knew too much. A class that peeks at globals and contexts beyond its own: it can't travel, can't be tested alone.
• The jack of all trades. A class that does everything: every new requirement makes it grow instead of growing the system.
• Repeated conditionals. The same if/switch showing up in several methods: that's a type hierarchy begging to exist. Polymorphism doesn't delete the conditional, it centralizes it in one place.

5His contrarian stance: Service Locator first

Where most modern literature treats dependency injection as dogma, Zandstra weighs it like an engineer. The Singleton? Dangerous if abused, but "I think that moderate use of the Singleton pattern can improve the design of a system" (p. 284), to be deployed "sparingly and with care". Full DI containers? "Dependency Injection offers purity, but it requires another kind of embedding. You must buy in to the magic of the assembler" (p. 329). His own choice: "I tend to prefer to start with the simplest solution and then to refactor to greater complexity, if needed. For that reason, I usually opt for Service Locator" (p. 329). You don't have to agree; a book that argues instead of reciting is worth more.

6The anatomy of Doctrine, rebuilt by hand

Chapter 13 builds, piece by piece, what every PHP ORM hides under the hood. Data Mapper: a class whose only job is to move data between objects and tables, "the great strength of this pattern is the strong decoupling it effects between the domain layer and the database" (p. 513). Identity Map: a registry that guarantees one object per database row, no double loading. Unit of Work: the notebook that tracks what's new, dirty or deleted, and writes everything at the end. Lazy Load: the collection that only queries when accessed. Read this chapter, then open Doctrine's source: you'll recognize every organ by name.

7A mini-framework named woo, to prove there's no magic

Chapter 12 assembles the enterprise patterns into a small framework the book calls woo: a Front Controller that receives every request, commands that interpret it ("commands are a kind of relay station", p. 443), an Application Controller that picks the next view, a Domain Model that knows nothing about the database. It's a Symfony skeleton in miniature, built under your eyes. Zandstra is honest about the price: this architecture "is not for the fainthearted. It does require a lot of up-front development before you begin to see benefits" (p. 449). That's exactly why frameworks exist: to pay that price once, for everyone.

8Development doesn't end with code

The third part is a statement: knowing how to design isn't enough, you need the ecosystem that makes delivery repeatable. "Development doesn't end with code" (ch. 14). Composer and semantic versioning, Git, PHPUnit and mocks, standards (PSR-1, PSR-12, PSR-4), continuous integration. The tools chosen in 2021 have aged unevenly (Vagrant and Phing have lost to Docker and GitHub Actions, Jenkins survives in enterprises), but the claim itself has aged perfectly: a developer who masters objects and patterns yet can't test or version is only half a developer.