My reason for using design patterns, sometimes, in PHP.

Firstly, a brief look at what a ‘design pattern’ actually is by looking at the definitions of both words:

Design
“to make or draw plans for something”
- https://dictionary.cambridge.org/dictionary/english/design

Pattern
“a particular way in which something is done, is organised, or happens”
- https://dictionary.cambridge.org/dictionary/english/pattern

So my understanding of that in relation to programming is a planned out way of organising and writing code so that it follows agreed upon patterns. Why does code need to be formalised in such a way? Well, it makes it easier for teams to work together by following a common and agreed upon set of patterns. If the patterns are known outside of the team then it also allows for future growth by bringing people in to the team who already understand them.

Design patterns can be used beyond one programming language and this therefore makes knowing them a lot more useful should an individual or team need to switch between languages. It is very similar to how natural languages such as English, French, Chinese and others, all have common constructs or patterns within them to help everyone who knows those languages understand how to interpret collections of words and sentences.

So why do I use design patterns in PHP ‘sometimes’? The ‘sometimes’ part is because not everything needs the complexity that design patterns can sometimes bring with it. In a professional environment, the code you write just needs to solve the problem in any way necessary. If the problem is small, contained to one specific area of the application, and is not overly complex, then trying to use all known design patterns to solve the problem is overkill. It does not mean that other good practices are forsaken, such as good variable and class naming, unit tests to ensure expected output is correct, readable code for the next person. It just means the problem will be solved more simply and usually in a lot less files and code.

I work in a relatively small development team so the impact of using design patterns is not always felt however the introduction of some of the key design patterns widely known and used in the industry has benefited the team in many ways. Introducing design patterns into a team is something that everyone has to be on-board with otherwise you can start getting code that aims to follow the design patterns but doesn’t quite meet the standards of those design patterns. The design patterns that are allowed in your company needs to be documented somewhere so that everyone can use it as a reference to know how certain problems have been solved in the past using design patterns that everyone is already aware of.

Here are some of the design patterns that I use and why they are useful in the web architecture that I work on.

Factory pattern
I use the abstract factory pattern and also the factory method pattern in PHP. The abstract factory pattern is very useful in defining an interface for a class that will be used to create specific types of objects. The biggest usage of this is alongside the data mapper pattern to allow data from databases to be represented in object form. The factory method pattern is often defined in the parent class so that it can create instances of the child classes based on a given set of criteria.

Singleton pattern
Although often frowned upon in PHP because it is just like using a global variable, the singleton pattern is useful to use in those areas of the code that do not need to be overly complex. Sometimes you do need to move code away from using a singleton however that happens when the requirements change from the original specification. If you do not need to write code and spend lots of time making sure that some day your code will support multi-datacentre or cloud integration then don’t. Just make sure your code is readable and consistent so that others on your team know how it works and how to use it.

Adapter pattern
In PHP, this pattern became useful during extension upgrades that changed how we interact with their functions. One such example was during the upgrade from MySQL to MySQLi. In our application we needed a way of interacting with a MySQL database, so we often used the native functions (mysql_query(), mysql_fetch_assoc()) defined by the MySQL extension. MySQLi, the new extension, introduced new native functions and even a object interface that would need to be used in order to move from MySQL to MySQLi. This was a lot of work and how would we know that our connection code, query code, and other processes were properly converted to MySQLi? We needed a more structured way of dealing with the transition, so that our code could support MySQL in the production environment while we tested and updated the code to use MySQLi in the development environment. We wrote an interface on top of the MySQL/MySQLi extensions that was specific to our needs and covered common usages of database interaction that we use in our application. This pattern helped us successfully move from one extension to another without too many issues. It also means that we may not be tied in to MySQL in future either with new adapters written for any database software we may need as the application grows.

Decorator pattern
The usefulness of this pattern so far is in the caching layer that we use in front of our database software. It separates the database access from the cache access so that it becomes clear when the data is being retrieved from the cache instead of directly from the database. In most circumstances the read requests from a database can be cached, with the write requests needing to hit the database connection directly. Read requests are more common than write requests and benefit from being cached after the hard work to retrieve and transform the data is done.

Strategy pattern
Applications usually have a lot of different ways of doing things based on client needs, user needs, system needs. Therefore the need for different strategies, algorithms, flows in the application is always necessary. This pattern defines an interface so that the chosen strategy can be interchanged with another very easily. By encapsulating a particular strategy or algorithm it is also possible to re-use it in other parts of the application without having to re-implement it again.

The goal and purpose of using design patterns in PHP that I have seen over many years of using them are:

• Easier to work on other people’s written code and understand the higher purpose of what it is trying to achieve. The programmer can understand the pattern before they fully understand the code. It makes programmers on the team think about the planning stage before jumping to the final solution.
• Unit tests become easier to write because the code in the test and the code in the application often look exactly the same and are used in the same way. Some patterns will also make injecting mock objects or using mock data much easier resulting in more high quality and robust tests.
• They help reduce mistakes due to code re-usability. They can also provide the ability to use simpler interfaces rather than more complex ones based on the needs of the application.