There has been a recent resurgence of trolling the use of "Facades" in Laravel and in other PHP projects as well. The recent storm comes on the heels of a massive trolling of the framework under the guise of "education" while mocking other developers, and claiming that they are hindrances to new developers in the community. I voiced my opinions shortly saying that beginning developers won't know the difference, and from there they will likely do more research. Before calling in to question whether the "not a Facade", Facade isn't getting too much attention for not performing its duties, I'd like to discuss how detrimental this is to the programming community.

Does This All Really Matter

Let's say for the sake of arguing that the Facades in Laravel, are just horrible abominations to the Facade Pattern have nothing to do with the concept and just in general lead thousands of Lemming developers astray: does it really matter? At first glance, if one is to read the Laravel documentation and the app directory, one would be more introduced to aliases and the IoC container in general. If you dig more and find the table listing the various Facades and what they point to, you might notice the word Facade. Heck, you may even write a package or two that extend Illuminate\Support\Facades\Facade.

At this point you might look at what that class is doing and find that it is rather cool how this "Facade" allows you to statically call methods and have them called on the resolved instance from the IoC container (with all the resolved dependencies as well). You may read some cool resource which mentions that the Facades even wrap the API for mockery allowing really easy testing while maintaining an incredibly concise controller codebase.

But, the real bummer comes when you try to work with something outside of Laravel. You will be shocked when you see that these other things calling themselves facades abstract APIs from multiple dependencies. Some may not allow you to use static function calls. Others may only give you a rather limited set of the underlying API in the name of simplicity.

OH! THE HORROR! What will we do? Never has something been this confusing in the world of naming things in Software Architecture.

When you return from the "Taylor Otwell Center for Kids Who Don't Know How to Proxy Good and Want to do other Things Good Too", you may find other patterns have naming problems too. If you dare read any college level software architecture book, you will learn that the true MVC pattern doesn't perfectly match Symfony, Rails, Laravel, or Django. Heaven forbid, you look at MVC (or pretty much any pattern really) in Javascript. Your mind just might explode at the inconsistencies. For there is no way that the Gang of Four or anyone who came before or after them could be wrong. Software Patterns shall not evolve, change, or be interpreted!

Let's get real though. The process in many cases goes like this:

Don't know what the heck facades are but like that you can write View::make...
Learn about DI and really like that you can write DB::table...
Learn that you can inject Illuminate\Cache\Repository instead of using Cache::...
Use a different software that has a different definition for "Facade"
Do some research on what the Facade pattern is
RTC and understand what each interpretation of the Facade Pattern is accomplishing
Make your own decision

Really, I think that as the high and mighty developers that we eventually think that we are, we fear every single bump along the next developer's path. We act like people that are just learning are mindless monkeys (that is a bit of an insult to monkeys sometimes in the way we sometimes treat junior devs). Honestly, we make this big of a deal about the terminology of one of the smaller design patterns while not mentioning the scope creep of foreach loops?

Is it a Facade?

Well, if you look at it in reality, (and Taylor has mentioned as much), Laravel Facades are proxies. They wrap around and call functions on the underlying true implementation of the code. Further, in the context of a Laravel application, these Facades are accessed by assigning them to aliases. This use of the Dependency Injection container allow you to reference something like Illuminate\Support\Facades\Filesystem by simply calling File.

Now let's look at the Facade pattern. From my experience with software architecture, Facades are abstractions to hide away a more cumbersome API to ease use and testing. They have a good some of knowledge of the underlying classes and often incorporate helper functions to further simplify an API for common actions which would take multiple steps using the original API. The last thing that many sources tend to cite when talking about Facades is that they often (not always) are handling multiple dependencies at once and meshing these APIs.

Now this is where I will get the most flack, and if I am wrong, feel free to say so (not in a hateful way, because I won't put up with it). But, doesn't it seem like the "proxy Facade" in Laravel accomplishes many if not all of these requirements? All of the built in Facades, handle the idea of resolving an instance from IoC. Some facades, such as Illuminate\Support\Facades\Input create helper functions to further ease the API. The biggest breakdown it would seem is the fact that most of these "Facades" only proxy their request over to a different class (often Factories, Resolvers, or otherwise).

But, just because it is a proxy, does that mean that these things can't also be Facades at the same time? They still clean up the API, they still hide the onslaught of dependencies required to make some of these things happen.

So, do you agree with me? Am I completely wrong? Did I fall asleep too much in my CS courses?