For as long as I’ve been writing on this site, I’ve used a combination of syntax highlighting, GitHub gists, or code or pre tags to help share code relevant to a given post.
But the more technical articles I read and the more that I see we, as an entire industry, start to rely versus utilize tools of Stack Overflow and other sites, the more I wonder how much we really understand what we’re writing (or even care) so long as the end results just works.
This isn’t a commentary on how quickly we should ship something. Instead, it’s about how we solve a given problem while also truly learning what it is that we’re incorporating into our codebase.
In previous posts, I’ve talked about the idea of focusing on an area and going deep rather than wide. This is personal preference, of course, but it’s mine, nonetheless.
Over the last year, though, one of the byproducts that I’ve found is the longer you stay in a given industry, the more common certain problems become. (This shouldn’t come as a surprise as this is precisely why we have design patterns.)
But the thing about doing this is that you develop a sort of tunnel vision for ways to solve problems.
Case in point: Recently, I was tasked with needing to develop some functionality that was going to parse markup and convert it into a slightly different format.
The content of this post is essentially the text version of the talk that I recently gave at WordCamp Atlanta 2019. Sure, some parts are left out, and some parts are modified but I do that since this is a different medium and certain statements or examples don’t translate as well. 🙃
The purpose of the talk, as you can tell from the title, is presenting a case for building web applications with WordPress.
I believe it can be done – because I’ve seen it done and worked with teams who do it – but before actually looking into the reasons why I think it’s a good foundation for certain applications, I also want to clarify terminology that we toss around a bit.
Ultimately, I want to define my terms so there isn’t any confusion, and then I want to use said terms to move forward.
But enough of the setup, right? Here’s the content of the talk.
How many times have you looked at someone’s code and stated:
I’m not using this because it doesn’t look well-written.
And in this case, “look well-written” might either be a substitute for:
“look like how I would write it,”
“seem to make sense to me.”
Sure – there are times where using open source code is risky. We know this from the various software and services that show up with vulnerabilities. But, at least for this post, treat those as the exception – not the rule.
This means we’re left with looking at something we may use but opt not to use because it doesn’t seem to be written in a way that we think it should be written.
In my experience, the way we first interact with the repository design pattern often influences how we think about the pattern. (The whole first impressions are lasting impressions, right?)
The purpose of this post is to show how it can be implemented in WordPress specifically when writing object-oriented plugins to read data (writing data may be covered in another post), but before doing that I tried to think of a few consistencies among the variations of the pattern that I’ve seen.
Generally speaking, this is what I think a repository pattern should do:
provide a single place to read data,
abstract the details of how the data is accessed,
and have a consistent interface for doing so.
This means that whatever it is you need to retrieve from the application can be retrieved from the database. But how its retrieved can be considered a black box. That’s up to the developer implementing the pattern.
And in the case for those who read this post, that’s most likely us.