A few months ago, I did a series of articles on Design Patterns in WordPress that was meant to provide an introduction to object-oriented design patterns, and how they can be used when developing projects on top of WordPress.
When it comes to working with WordPress, code is normally written one of two ways:
- Procedural
- Object-oriented
For procedural programming, think of `functions.php` in theme development, and for object-oriented think of plugins. This isn’t to say that procedural programming isn’t used in plugins – it often is (case in point: Markdown Code For WordPress) – but so are object-oriented techniques (see the WordPress Plugin Boilerplate).
In short, decide patterns exist for a reason: They are proven solutions to common problems that appear in software development.
Yes, they may have to be tweaked a bit for a given situation, but the definition, structure, and so on remains the same. The thing is, I don’t often see many design patterns used throughout WordPress product development.
To be clear, I’m not talking about WordPress core, I’m talking about products built on top of WordPress. Perhaps I’ve just not done enough digging or paid enough attention to some of the work that’s out there, but I think if we – as developers – spent time working on implementing design patterns in our work, projects could have much more longevity rather than devolving into spaghetti code that’s so often found in WordPress work.
Design Patterns in WordPress
So, I spent a significant portion of the first part of my career working at a large company working on .NET applications. And, like they say, the more code you write, the more you begin to notice the same problems emerging again and again.
They just take on a slightly different form. This is a perfect example of when a design pattern is likely to fit the bill.
At this point in my career, the same can be said for WordPress. There are correct ways to perform certain actions and there are ways to do things that just work.
As with any programmer, as I look back at code that I wrote even 8 – 12 months ago, I cringe. But if I look at the stuff I’ve been working on, I’m more pleased. But give it 8 – 12 months and I’ll likely cringe again.
Such is the developer’s life.
Anyway, with that said, I think that we’re also starting to see certain patterns – or at least conventions – arise in theme development with the organization of things such as Underscores. Directories are laid out a certain way, code is written a certain way, and so on.
So perhaps it’s safe to say that if it’s not patterns, at least aim for conventions.
But with all of that said, why should we – as developers – bother with using and/or evangelizing design patterns in WordPress?
1. Education
Personally, I think that WordPress provides a solid platform on which to introduce budding developers into software development.
The application is full stack from database to the front end and there is potential to use variety of technologies. It also supports plugins (or add-ons) and gives them a feeling of what it’s like to work on a significantly larger team thanks to the open source nature.
Design patterns in WordPress can help to further educate developers on patterns that have been around for decades, why they matter, and how to use them.
2. Productivity
The more code that you write, the more likely you are to see common problems appear throughout your work.
Using design patterns makes your work more maintainable, arguably more readable, and improves the maintenance factor far more than using things such as spaghetti code.
It can also help to provide a stronger conceptual model of the architecture of a product because its fitting in to a sort of predefined architecture – or, well, ahem, a pattern – that makes it easier to keep track of the various moving pieces of the application.
3. Contributions
One of the defining factors – if not the defining factors – of open source software is the ability for anyone to introduce contributions to further develop the product.
If said product starts off by following a defined paradigm, then it makes it significantly easier for contributions to know where new code should code, how it should functions, and how it should interact with what’s already defined.
This is a much better alternative than letting people provide patches that solve a problem, but do so in a sloppy, difficult to maintain way. Of course, the patches that are introduced like that aren’t always a result of the contributor, but the core software itself. But I digress.
The Double-Edged Sword of WordPress Development
One of the greatest strengths that WordPress has is its low-barrier of entry for anyone to get started; however, I think that this is a double-edged sword.
Yes, it’s easy to get up, running, and programming with WordPress; however, the nature of some of the languages that are used throughout make it far too easy to simply get something working rather than taking the time to educate ourselves on the WordPress-way to do it, or even the more elegant way to do it.
At any right, I think evangelizing design patterns either through implementing them more in our own work, discussing them more on our own blogs and articles, and educating others on how to use them could go along way in not only attracting other software developers, but making us better at what we do, as well.
Leave a Reply
You must be logged in to post a comment.