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
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:
- It checks the error manager to see if there are any errors and then asks the error manager to render them if they exist.
- 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:
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.
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.