Design Patterns for Refactoring: The Facade Pattern

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.

A Word About Design Patterns

When it comes to working with software, design patterns are one of those things that really are quite powerful. Sometimes, though, I can’t help but think we throw around pattern terms or pride ourselves on using a certain type of framework because it implements a pattern rather than actually know why a pattern may be beneficial or not, and why and when it’s a useful thing.

Maybe that’s just me.

Big Ball of Mud
Your team lead, your team, and your source code.

But one thing that’s easy to observe, at least within the context of WordPress development, is that we’re not really big on patterns. Sure, we use the event-driven pattern that WordPress provides because we have to, and there are some people who look at Inversion of Control, Dependency Injection, and all of those other terms that sound more complicated than the ideas they represent (no, I’m not opinionated about that at all), but there’s not a lot of work involving patterns.

Instead, when it comes to working with object-oriented code, I think we see god-classes more than we see anything else.

That’s no good.

And there’s a lot that could be said about this. We could talk about the SOLID principles, we could talk about coupling and cohesion, or we could continue to ramble on about all of these things without taking a deeper look at something that’s actually applicable.

Design Patterns for Refactoring: The Façade Pattern

Everyone loves to have a single, prescribed solution for how to solve a problem. That’s why we love algorithms (and it’s why we love copy and paste more, isn’t it?), design patterns, plugins, and so on.

But there are actual strategies that we can follow in order to thoughtfully go about refactoring our code and improving the internal architecture. And though there’s no a single right way to go about doing something, I think that the Façade Pattern can be incredibly useful in working through a refactoring.

It Gets Worse Before It Gets Better

Before actually looking at the pattern, assume the following:

  • You have n-number of classes, say, 5 classes, each of which are responsible for something else.
  • These classes have high coupling, low cohesion, and could stand to be completely rewritten.
  • The degree to which they depend on one another is so high that it’s hard to actually begin breaking things apart without breaking the program.

So how does the whole facade pattern thing fit into this? Think of it this way: The facade is an intermediary class that sits in between code that calls into the highly-coupled classes and then redirects all incoming requests to said classes, then directs all responses from said classes back to the caller.

So here’s a simple diagram straight form Wikipedia on the Façade:

The Facade Pattern
The Facade Pattern. Boring.

It feels a bit counterintuitive at first because we’re basically giving one class all of the knowledge that exists in the other classes and then having it serve as a means by which data is passed and returned to the calling classes.

But I like to think of it this way: Let’s say this is your code sitting with the Façade (where Superman is the façade):

The Super Façade
The Super Façade

So what should the work look like once we’re done and the proverbial Superman has been removed from the situation?

Your set of classes after being refactored.
Your set of classes after being refactored.

Not bad, right?

Is This Not an Anti-Pattern?

I mean, is the façade in an of itself a god-class? In a way, yes, but the purpose that it serves is meant completely defy the anti-patterns that exist within the code itself.

During the time that the façade is sitting as an intermediary, we are free to begin breaking about the poorly designed classes that sit behind it into something that’s far more well designed. As we continue to make these improvements, the façade can then handle communication between the callers and the new class until eventually the callers can be made aware of the new class.

By the end of the refactoring, we’re able to remove the façade and then have the callers use the newly refactored classes (which should obviously yield a better design and easier maintenance over time).

Worth an Example?

Despite the fact that I’m more interested in showing a practical way to go about doing this – even if it’s using somewhat of a contrived example – it’s a harder topic to cover in a single post. If this is something you’d like to see covered in, say, a series of posts, then let me know in the comments and it’s something that I’ll look into doing.

If not, no big deal. Hopefully the post has given enough information and tips for you to research some of these strategies on your own so you can take that big ball of mud and making it something much nicer than what it currently is.

Those who use the product may not necessarily notice any of the changes, but those who are responsible for maintaining the project moving forward will definitely appreciate the de-coupling, greater cohesion, and so on.

4 Replies to “Design Patterns for Refactoring: The Facade Pattern”

  1. I dig the analogy with Superman and the Avengers, Tom. Coming from an enterprise software and hardware implementation and go-live support background, this is a common pattern useful in code, interfaces, and systems and data migrations, where a “temporary” solution is introduced to represent the previous way of doing something until the new code/functionality/interface/data standard can go live. To all outside parties, it looks the same as it always has been. A fundamental best practice to support this approach is that the amount of changes required of the temporary solution are either frozen, or severely limited to in scope, complexity, and cost until the new code/system/interface goes live. Why? Think of it this way: if you take a picture of the code today, and then again at the end of the project, how many changes would you be able to spot? Thus, the idea is that every change that gets made to the packages during this period, and to the facade itself, needs to be reviewed, approved, implemented, and regression tested, so that when the facade is removed, everything works according to the last change implemented — not just when the facade was first introduced. Obviously, for these reasons, most clients with sensitive production environments will try to minimize their risk of something going wrong by limiting changes and trying to get the code refactoring done as fast as possible. As this is another tool in your toolbox, you will want to compare the ease/complexity and duration of this change control method with others you may have at your disposal when deciding how to go about your code refactoring project. There are often more than one way of getting it done, and I for one look forward to more from Tom on this subject.

  2. An example would be great. When I hear facade, I think of it in the Laravel sense along with aliases to make it easier to mock in testing and handle long namespaces easily. Is that on the right path to what your talking about, or is it off the mark.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.