Book Review: Practical Design Patterns in PHP

This review of Brandon Savage’s Practical Design Patterns in PHP will include my own opinions and impressions about both the book, and the aspect of self-publishing. Many thanks to Brandon for giving me a review copy.

Design patterns are about common solutions to common problems.
… they are concepts, not blueprints; ideas, not finished designs.
… they add clarity to an otherwise difficult situation.
– Brandon Savage, Practical Design Patterns in PHP

Key Takeaways

• “Practical Design Patterns in PHP” by Brandon Savage offers a comprehensive guide to understanding and implementing design patterns in PHP, with a focus on common solutions to common problems. The book covers a wide range of patterns, each explained with potential code implementations, making it a valuable resource for intermediate-level developers.
• While the book’s content is praised, the review notes some shortcomings. These include the lack of explanation for certain patterns, such as the Registry Pattern, and the assumption that readers are familiar with advanced concepts and third-party content. The review also criticizes the book’s approach to models in MVC applications and the lack of practical examples for the Domain Model Pattern.
• The review highlights the challenges of self-publishing, as seen in the book’s lack of professional guidance, language errors, and occasional oddities in code samples. Despite these issues, the book is recommended for intermediate developers looking to delve into design patterns, but not for beginners who need to master basic concepts first.

Content

Starting out on a lighter, introductory note, Brandon explains the need for frameworks, argues that OOP doesn’t mean just wrapping stuff in classes, and goes into detail on why design patterns appear to be difficult to learn. He then continues with a mild introduction into SOLID principles, and lays the groundwork for more advanced concepts. He explains why each SOLID rule is important and what it means. Given that SOLID is a well established software design principle, it’s only natural to compare it against every pattern that’s about to be explained in the book. Or, to be more precise, to assess how well each pattern respects the SOLID principles, while providing the developer with its intended functionality.

If I express matters in Dreyfus model terminology, he claims the book is there to turn a novice into a competent level developer without subjecting them to advanced beginner mistakes when, in fact, such an approach to learning is not entirely possible – that’s just not how the human knowledge acquisition process works.

---

As it might not be overly evident from the ToC, the patterns explained in this book are, in order:

• The (Abstract) Factory Pattern
• The Singleton Pattern
• The Builder Pattern
• The Decorator Pattern
• The Adapter Pattern
• The Bridge Pattern
• The Facade Pattern
• The Strategy Pattern
• The Mediator Pattern
• The Observer Pattern
• The Chain of Responsibility Pattern
• The Iterator Pattern
• The Composite Pattern
• The MVC Pattern
• The Domain Model Pattern
• The Active Record Pattern
• The Front Controller Pattern

With so many patterns covered (and most covered well), I was surprised to see a sentence such as “[…] For example, the Registry Pattern (not covered in this book)…“. Why not? The Registry Pattern is a popular pattern, and very simple to explain even if it isn’t exactly recommended nowadays.

Pattern by pattern, each is explained well and most are followed by code examples demonstrating their potential implementation, though I do have a gripe with the factory pattern example with the cache.

The pattern is realized on an example of different caches – APC and Memcache – and both are spawned through a factory, which is injected into whichever service needs a cache component.

It makes sense to me, but I can see less experienced people wondering why one might actually need the Factory step at all, and not simply type hint the cache interface itself in the constructor, requiring the injection of the cache object itself, and not its factory. The current example features both a Factory interface and a Cache interface, and at the very least, one seems like a surplus. This was never explained in a mid-level developer approachable way, and I fear it may be confusing to some. I’m also less than happy with the Bridge pattern’s explanation – it seemed lacking, like it was only scratched at the surface, never to properly return.

On the other hand, I absolutely loved the Composite pattern explanation and its demonstration on very interesting Tree examples – the author builds a composite tree with an arbitrary number of nested node levels which applies fantastically to menu construction, hierarchy representation, and more – and I was particularly thrilled with the Decorator pattern explanation. It was done in a very approachable way and on good, usable examples. This pattern in particular was one I’ve always had difficulty explaining to people out of the blue when asked, and I’ve yet to find a better breakdown than in this book.

Neglect of Models

In one instance of the book, Brandon says that models are the heaviest lifters of an MVC application, containing all the business logic and validation code. This is a statement that’s far too absolute for me to accept – off the top of my head I can think of an example where this is not true: Laravel. With Laravel 5 coming out and adding Form Requests, the models will be growing even lighter.

Granted, some people tend to put everything and the kitchen sink into the models, but there are people who put the same amount of god-code into controllers, too. My experience and preference say that everything framework-related should be very light (small controllers, small models, small or no views), and everything service-related (services, plugins, libraries, helpers) can be as fat as they need to be, as long as they’re inter-operable between frameworks. That’s personal preference though, I suppose. One other thing struck me as odd, though:

“Creating good models is one of the most complicated tasks any developer tackles. For a long time, the Zend Framework documentation held that there was no Zend_Model class because creating a model is the bulk of an application development process. To create a Zend_Model would be to assume that everyone could or would want to use the same model structure, which would be impossible For the same reason I haven’t included any code in this chapter.”

While this does make sense, exemplifying the value, gateway and storage object in the simplest of manners would have been incredibly beneficial to people being introduced to the domain model pattern for the first time. The Domain Model Pattern was, in my opinion, too neglected and far too theoretical in this book.

The Curse of Knowledge

Throughout the book, Brandon makes references to advanced concepts (ORM, inheritance, dependency injection) and third party content without linking to it (Gang of Four), assuming the reader is familiar with it all. The Gang of Four in particular is mentioned on several occasions, and could use at the very least a link to Design Patterns – else the “novice” and “advanced beginner” reader will just glance over the sentence in confusion.

In other cases, the paragraph structure is written in a way that’s far beyond the level of understanding for a novice to intermediate user:

It’s an age old question many developers struggle with all the time: if I am working to invert my dependencies and not create objects inside my classes, how do I go about creating the dependencies that I need during runtime that can’t necessarily be injected?

This is not at a level that’s consumable by the reader who would need this book to become familiar with the patterns. The reader who understands this sentence in full is likely already fully familiar with all the patterns in the book, thus bringing into question the real target audience. I believe this is due to Mr. Savage suffering from what is known as “the curse of knowledge“.

Wikipedia defines it as such:

The curse of knowledge is a cognitive bias that leads better-informed parties to find it extremely difficult to think about problems from the perspective of lesser-informed parties.

The curse of knowledge is a very common occurrence in professionals who aren’t formally trained to pass on what they know, but is also something that does lose effect with time, experience and feedback. This is also why we at SitePoint encourage people to give us honest feedback about our posts, and is why we try to make things simpler and more streamlined with every new publication. No one is immune to the Curse – some are just more affected by it.

The Plague of Self-Publishing

In recent years, self-publishing seems to have really taken off. Those that don’t resort to Leanpub go fully solo, like Brandon did with this book. While this approach does indeed speed the process up and allows experts to put quality content into the hands of interested parties at an alarmingly rapid pace, it also allows for more mistakes, bad content, and typos to slip through.

Most of the problems that plague other self-publishing writers also, unfortunately, plague this book. Lacking an experienced editor, there seems to have been no guidance on content, form or even grammatical and syntactical accuracy – something people who are native to a language often mess up.

Thinking that native speakers don’t make mistakes and thus don’t need formal editing is akin to, for example, a Y-based company hiring someone from country X to proof-read their X-language version of the site on the sole grounds of the proofreader being a native speaker of language X. You really wouldn’t want to hire me to proofread your Croatian version of a website even though it’s my native language, but you’d be hard pressed to find a better English language editor.

Conclusion

As an advanced user, I had previous knowledge of most if not all the patterns explained in the book. However, the explanations I went through were well formed and approachable to an intermediate user – though in my opinion, not to one of lower skill. While the content of the book is very good and Brandon is excellent at demonstrating in code what the theory describes, I feel like the book as a whole is far too complex for the newbie developer to get anything tangible out of.

The PHP community in general, it seems to me, is suffering from a sort of “missing link” syndrome where we have the absolute beginner books (“this is echo, this is a function, this is a php tag”) and the intermediate books like this one, or anything Sturgeon, Jones, Hartjes and others have put out, but there’s a middle ground that remains void of quality content and can only be conquered via the good old “throw me into the fire” approach.

That said, if you’re an intermediate developer looking to get into patterns and out of those awkward nods at conferences where people standing around you talk about them but you don’t understand a thing – definitely get this book. If you’re a newbie, I can’t recommend you buy this – not just yet. Master your “echos” first, learn what Composer is, then sink your teeth into this one.

In fact, if you ARE an advanced beginner (beginners should start at the very basics) who’s interested in patterns nonetheless, I applaud you and offer the following resources to look at before you dive into this book:

• Elements of Object Oriented PHP on Learnable
• Object Oriented PHP
• Object Oriented PHP applied: Making Two Armies Fight Each Other
• Awesomeness by Alejandro Gervasio – read everything this man ever wrote
• Composer
• MVC

Content-wise, I’d give the book a 4/5, but taking into consideration the rush job it appears to have been near the end, the typos and language errors (though to be fair, there is a typo submission Github repo which I’ve already polluted with fixes) and the evident lack of professional guidance along with some oddities that I personally believe will embed wrong values into newbies stumbling onto this book (starting class names with numbers in various code samples), I’m ending the final score at 3/5.

Frequently Asked Questions about Practical Design Patterns in PHP

What are the benefits of using design patterns in PHP?

Design patterns in PHP provide a reusable solution to commonly occurring problems in software design. They offer a way to improve the efficiency and maintainability of your code. By using design patterns, you can make your code more flexible, reusable, and understandable. They also make communication between developers easier, as they provide a standard terminology for certain solutions.

How does the Decorator pattern work in PHP?

The Decorator pattern is a structural design pattern that allows you to add new behaviors to objects dynamically by placing these objects inside special wrapper objects. In PHP, this can be achieved by creating a decorator class that wraps the original class and provides additional functionality. The decorator class implements the same interface as the original class and holds an instance of it. All calls to the decorator are forwarded to the original class, and then the additional behavior is added.

What is the difference between design systems, pattern libraries, and style guides?

Design systems, pattern libraries, and style guides are all tools that help maintain consistency in design and development. A design system is the overarching structure that includes the philosophy, principles, and tools that govern the design and development process. A pattern library is a subset of the design system and includes the reusable design elements and components. A style guide, on the other hand, is a document that outlines the visual design elements, such as colors, typography, and spacing.

How can I achieve design consistency using pattern libraries?

Pattern libraries are a key tool in achieving design consistency. They provide a set of reusable components that can be used across different parts of a project. By using these predefined components, you ensure that the same design patterns are used consistently, leading to a more cohesive and user-friendly design.

What is the role of refactoring in design patterns?

Refactoring is a process of modifying existing code to improve its structure without changing its functionality. In the context of design patterns, refactoring can be used to implement a design pattern into an existing codebase. This can improve the code’s maintainability, readability, and often performance.

How does the book “Practical Design Patterns in PHP” help in understanding design patterns?

The book “Practical Design Patterns in PHP” provides a comprehensive guide to understanding and implementing design patterns in PHP. It offers practical examples and detailed explanations of various design patterns, making it easier for readers to grasp the concepts and apply them in their own projects.

Are design patterns only applicable to PHP?

No, design patterns are not exclusive to PHP. They are a concept in software design that can be applied to any object-oriented programming language. The implementation might vary from language to language, but the underlying principles remain the same.

How can design patterns improve communication between developers?

Design patterns provide a standard terminology for certain solutions in software design. When developers use these terms, they convey a specific, well-understood concept, which reduces misunderstandings and improves communication.

Are there any drawbacks to using design patterns?

While design patterns offer many benefits, they can also introduce complexity if not used properly. Overuse of design patterns can lead to unnecessary abstraction and can make the code harder to understand and maintain. Therefore, it’s important to use them judiciously and only when they genuinely solve a recurring problem.

How can I start implementing design patterns in my PHP projects?

The first step to implementing design patterns in your PHP projects is to understand the problem you’re trying to solve and identify if it’s a recurring problem that a design pattern can solve. Once you’ve identified a suitable design pattern, you can start implementing it in your code. Remember, the goal is to make your code more efficient and maintainable, so always keep simplicity and clarity in mind.

The above is the detailed content of Book Review: Practical Design Patterns in PHP. For more information, please follow other related articles on the PHP Chinese website!