I talk about design patterns quite a bit on this blog, though I don’t know if I ever really do a good job of doing a deep-dive into individual patterns, why I’ve used them, or even how they are structured.

I’m okay with that as I’m not always aiming to give tutorials on principles and patterns as I am on WordPress-specific programs, but let’s say you’re someone who wants to use a design pattern in WordPress and isn’t sure where to start.

Given all of the above, I thought it might be worth giving a high-level look at how I’m implementing a pattern in a current project – at least at a high level – and then where you can refer to other design patterns for your future work.

A Quick Survey of Design Patterns

From previous posts, we know that design patterns have various definitions, but one of the best descriptions I’ve found comes from the Source Making resource shared recently:

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

And that’s the key thing to understand: It’s not a finished project or design.

It’s a way to approach a common problem.

So here’s an example of a problem I’m facing and a pattern that I’ve opted to use.

The Repository Pattern

To give some context as to what this pattern is (or does), the repository pattern (in my words):

Orchestrates communication between the data layers and domain objects. It does this by keeping the objects contained and orchestrates communication between them.

Some may define it a bit more technically, and that’s okay. The thing about patterns is that, although I believe we should aim to keep them as pure as possible (and I try), sometimes you have to make a concession or two.

With that said, here’s how I’m using it: I currently have a single repository that maintains references to a class that manages error handling and data management (for reading and writing data).

Because I’m working with WordPress, the repository has to maintain a set of two hooks in which it does the following:

  1. It checks the error manager to see if there are any errors and then asks the error manager to render them if they exist.
  2. If no errors exist, then it asks the data manager to go through a process of orchestrating the data for some other entities [that are irrelevant] to this post.

Ultimately, the weak diagram looks like this:

Repository Pattern Example

A simple example of the repository.

The advantage is that the error class knows nothing of the data management class and vice versa. Furthermore, the other entities (such as customers, orders, products, and so on) are all unaware of one another.

The repository uses the knowledge it has to orchestrate communication among them. To be clear, it’s not like this god-class that maintains all knowledge and then tells one class what to do versus the other.

Instead, it only asks an object for its state then, depending on the state, asks it to do something else. And it essentially does that for the data manager, as well. You can think of it this way:

Try to load some data. If no data exists, then tell the customer what to do.

And the customer object then has the knowledge it needs to do to complete its work and so on with the rest of the examples.

Getting More Practice

If you’re looking to get a deeper understanding, then I recommend this post, but I also recommend this particular GitHub repository, as well.

Design Patterns in PHP

I owe Toby Schrapel a hat tip for reminding me about this (as it’s been a while since I’ve seen it). It covers all of the major design patterns and gives an example of what they look like in code.

To that end, I think getting an understanding what each pattern is like and what it does is important then reading the code for how it’s implemented is important.


Join the conversation! 1 Comment

  1. Hey Tom,

    It’s good you reiterate that point: A design pattern is not a ready-to-use solution you can copy-paste into your code.

    Design patterns are a communication tool, they provide developers that have very diverse backgrounds with a shared vocabulary, so that they have a common ground to start discussions. Otherwise, discussing advanced concepts would be very arduous and error-prone.

    That being said, from what you’ve explained above, I suspect you might be using the wrong “term” for what you’re trying to achieve.

    The Repository (also known as one half of the DataMapper pattern Link, the other one being the Entity) is an abstraction of your persistence. You use the Repository to request objects as if your entire dataset was available in memory. The Repository is then responsible for translating these requests into actual operations on your persistence layer (typically, your database).

    So, usually, your Repository will provide several find_*() methods to retrieve your domain objects according to specific criteria. As an example, you could have something like:

    $user = UserRepository->find_by_email( $email );

    You can then interact with your $user object (which is an instance of the Entity pattern in this case) without knowing whether it was in memory, came from the database or was loaded from the filesystem.

    It is difficult to know for sure based on the information you provide, but what you seem to explain might be an instance of the Mediator pattern Link.

    The world of design patterns is wonderful and horrifying, because using them as communication enablers assumes that everyone is always understanding them in the same way, which is very seldom the case.

    Would love to know whether my guess is right with the “Mediator” pattern, so keep me updated if you managed to take a look at the links.



Leave a Reply