Let’s Talk About Facades

There’s a lot going around right now about Facades. Laravel introduced the concept, or at least the term, to the PHP community in their framework. Given the popularity of the term, it’s worthwhile to define what a Facade is, and what a Facade is not.

The definition of a Facade

The Facade (or the Facade Pattern, which is what Wikipedia gets you for a search of Facade), is a design pattern. The intent of a Facade is to take a group of subsystems and create a common interface for each system so that higher level systems can use the lower level ones without having unnecessary dependencies. The Facade itself maintains the dependencies.

A Facade is very much like an Adapter, except that while an Adapter takes common interfaces and creates a single interface out of them, the Facade takes different and incompatible interfaces and creates a single interface from them.

This has a few advantages. First, it reduces dependencies among higher-level systems by creating a common, unified interface for lower level systems. Second, if the lower-level systems have poorly designed APIs, the Facade can improve upon the API design (see GD for example). Finally, a Facade helps makes code easier to read and test, since it simplifies the overall API and dependency tree.

Laravel’s use of the term “Facade” is wrong. Their Facades are nothing more than proxies for service location, providing a way to load objects defined at runtime, rather than actually providing a common interface to complex subsystems. Laravel’s “Facades” aren’t Facades at all; they’re simply service location.

Why does this matter?

One of the things that we do by defining design patterns is we create a common language that we can use to explain and express ourselves. When I say to you “I used an Adapter” or “I implemented the Factory pattern”, that should conjure up a specific image in your mind of object relationships and behaviors, even if you don’t know my specific use case or problem domain.

When we use these terms incorrectly, we not only devalue them, we confuse developers. For one of the most up-and-coming frameworks to use a technical term so incorrectly is disturbing. It breaks down the vocabulary that technical people use to communicate with each other, because there are now two very different definitions floating around with the same name.

Of course, Laravel’s Facades are in fact well-designed proxies implementing the Proxy Pattern. There’s nothing wrong with that: as a developer, it’s up to you to decide how and what patterns you’re willing to accept in your framework, and to write your application however you wish. All I ask is that we stop calling them Facades.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

There are currently no comments.

Copyright © 2023 by Brandon Savage. All rights reserved.