Tag: Design Patterns

Modern Software Engineering in WordPress (We Were on a Break)

October 8, 2019 / Tom

Over the past few years, I’ve spent a significant amount of time writing about a lot of things on how to achieve certain things in WordPress. And I don’t regret it (after all, it’s my career and it’s even the subtitle and focus of this blog).

But one of the things that I’ve opted to neglect is a focus more on topics that interest me such as object-oriented analysis, programming, design, and implementation. (And, of course, doing so within the context of WordPress.)

And sure, there are some articles where I’ve touched on it but I recently took a week off of pretty much everything except my [growing] family and during that time, I took stock of a variety of things.

One of those things included this particular site, its content, and the general focus of my career.

An Implementation of the Repository Pattern

November 16, 2016 / Tom / 0 Comments

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.

Design Patterns for Refactoring: The Facade Pattern

August 21, 2014 / Tom / 0 Comments

For some time now, one of the things that I’ve been considering writing about is the idea of refactoring.

Not necessarily in an incredibly specific sense – because each project is different – but in the sense of using some strategies that can help to take an existing project that’s running in a production server and slowly begin to refactor it so that its architecture changes but the functionality remains the same.

Anyone who’s worked in the software world knows just how nasty a codebase can get, and WordPress is no different. And I’m not talking about WordPress core – I’m talking about plugins, themes, apps, or whatever else it is that you may be building on top of WordPress.

For the most part, we start our projects with the idea that it’s going to have a great architecture, a pristine design, and that it’s going to basically be the best thing that we’ve ever worked with.

At some point, usually due to external factors, the thing devolves into a pile that we no longer want to touch, and we hope that it holds together to continue solving the problem at hand.

But it doesn’t have to be that way and even if the code you end up working with – be it your own, or someone else’s – has devolved into a big ball of mud, there’s still a strategy (probably multiple strategies) that you can use in order to refactor it into something far more elegant.