I've owned PHP Objects, Patterns, and Practice for over a year, and it's still one of those books I go back to. It's a well written, generally well executed book on what constitutes Object Oriented Programming in the PHP5 environment.
First, the good news:
This book is a crash course on OOP design and thought. It borrows heavily from two monumentous texts in the field - the Gang of Four's book, and Java Enterprise Patterns - and condences their essences into an easy to swallow form. The basics are all here: how to create well designed classes, how to instantiate objects, etc. There's a hidden gem in the introductory portion of the book: the Reflection API. This API is built into PHP, and gives the coder unparalleled access to the guts of the classes and objects in a given project. It definitely has its uses.
The patterns are all generally useful, with the only exception perhaps being the Interpreter pattern. I'm just not convinced that creating one's own command line interface syntax is necessary, given that PHP projects aren't usually interactive. It seems like something best left to an appendex, or extra web content.
Now, for the bad news:
Some sections of the book, especially some of the code examples, could've used a better editor. Small things, the kinds of things that can trip up inexperienced coders, crop up. Using private properties instead of protected. Using the wrong variable name between examples. That sort of thing.
There's also a lack of a satisfying conclusion, so-to-speak. Zandstra himself claims that generating objects is perhaps the hardest thing to demonstrate. Yet, most of his examples (excepting the patterns late in the book) are canned. Objects and classes exist only to drive the theory behind a pattern home. Few real world examples are given. Admittedly, some patterns are simple to transfer to a real project, but concrete examples of that nature could serve to further cement his point. For example, it's not difficult to see how the Composite pattern would work well for dealing with an XML document, but would there ever be a need for a Visitor object to act on one?
Finally, and in continuation of my last criticism, Zandstra never touches one of the things PHP is used the most for: form handling. Can forms be represented by classes? Could forms be generated by objects (perhaps using a Factory pattern)? What about form validators? Wouldn't the Strategy or Decorator pattern work? Supplementing his online Civilization game and CLI/quiz examples with this would've really put the book over the top.
Still, with that said, PHP Objects, Patterns, and Practice is still a text that gets far more right than wrong. It's definitely a must-buy for those PHP coders looking to write modular code.
