CakeFest organiser James Watts unravels the mystery of design patterns and how they provide a generic solution to common problems
Director at CakeDC – cakedc.com
James Watts has been involved in open source since around 2008, and using PHP for the last ten years. He’s a core member of CakePHP, organiser of CakeFest and is currently the acting director of CakeDC. He’s also an author, a speaker, community manager, husband and father.
For anyone who’s not familiar with the concept of a design pattern in software development, it’s basically a generic solution to a common problem. You can think of it as a blueprint, acting as a guide of how to solve certain problems or scenarios when developing software. You may have even been introduced to design patterns if you’ve ever heard the terms factory, adaptor or strategy.
From the world of HTML and CSS, you may have implemented a design pattern already. For example, the separation of structure and presentation, where the CSS rules and declarations are segregated from the markup structure and semantics of HTML, is actually a design pattern. Design patterns can also enable other developers to quickly understand or become associated with the way software has been developed if they can identify with certain patterns from the onset. This is of huge benefit to teams where agility at the development level is important, as assumptions can be made about the architecture or code base if patterns have already been applied.
In contrast, there are antipatterns, which are quite the opposite: design patterns which cause problems and obstructions in code and architecture. For example, concepts known as div soup or divitis are in fact antipatterns. There are also some very specific antipatterns in PHP, such as the use of globals, defining multiple classes in a single file or liberal usage of eval. These are also sometimes referred to as ‘smells’ in code.
But, where did design patterns come from? The prevalent usage and application of design patterns didn’t become popular until after 1994, when a book titled Design Patterns: Elements of Reusable Object-Oriented Software was published. This book really formalised and laid a foundation for design patterns to be taken into the mainstream of software development, and still remains a core book for anyone who is serious about building robust code which can stand the test of time.
As an example, let’s look at the factory pattern, which is probably one of the most popular patterns found in any language. This pattern is used to create instances of classes, without exposing the instantiation details. So, first, the problem:
$car1 = new Ford(‘blue’, 4); $car2 = new Toyota(‘red’, 2);
Here we’ve created two cars. One is a blue, four-door Ford, while the other is a red, two-door Toyota. Both of these classes extend a base Car class. Notice how we’ve directly instantiated each of these with their class name, passing the details for each. The problem here is that we have no control over the instantiation logic when creating these objects, so if they’re created at 200 locations over the code base, and we want to make a change, we’d have some work on our hands.
The factory pattern resolves this issue by introducing a single point of creation. The previous code would change to the following:
$car1 = CarFactory::create(‘Ford’, ‘blue’, 4); $car2 = CarFactory::create(‘Toyota’, ‘red’,2);
If we now want to change how cars are created, or introduce additional implementation specifics we need only to change that on the factory.
In my more than ten years of experience in professional PHP development I’ve found design patterns to be an invaluable ally when building clean and consistent code which scales. It’s important to note that scale doesn’t just mean infrastructure and performance, it’s also affected by the development team’s ability to grow and advance with the code base. A messy core, full of one-time hacks and creative patches to get things working can be a business’ Achilles heel when the time comes to building out.
These tricks got the necessary results but can become the bottlenecks when features have to work around the mess, and the onboarding of new recruits becomes slow and expensive due to all of the artistic approaches taken in the code.
The use of design patterns can not only increase the quality of a code base, but also improve the way you approach problems. In an industry where the NIH (Not Invented Here) syndrome is widespread, building on the shoulders of giants and leveraging the experience of many who have come before you can give you a notable advantage when it comes to writing clean and elegant code like a pro.