What is Laravel Facades:

Facade Design Pattern:

Facade pattern hides the complexities of the system and provides an interface to the client using which the client can access the system.

It flies right over my head huh! So what Facade design pattern is essentially saying is that I will provide huge functionality to you, you just have to ask. It’s just like using a library which does all the heavy lifting but you just have to ask the library via its fluent API/functions.

In above example FacadePatternDemo is asking for functionality using one central class ShapeMaker. Whenever you need functionality you always go to a central place ShapeMaker (it’s like one stop shop). Now the thing on the left can grow in complexity and maybe dependant on several additional layers which are not shown here; but you are not are not concerned with this as long as you keep on asking from your central class (the interface to the complex functionality).

Facades in Laravel:

Facades provide a “static” interface to classes that are available in the application’s service container. I can’t understand this either at least in the start!, let’s break it down:

Laravel does two things; it’s saying I will not only provide the huge complex functionality, but also give you way of asking me in such a way which is less work and is beautiful to write.


Now how would you use Greet:

Laravel’s facade way of say this is:

Now before I tell you how it works we need to know the service container.

For starters it is just a global big array of key values; consider this

Laravel uses PHP mechanism ‘Reflection API’ under the hood to resolve the classes. What we are saying here is that every time I ask for key ‘Greet’ anywhere in my app, Laravel knows how to resolve it and would give me an instance of Greet class.

Now how it is calling ‘sayHi’ statically although we haven’t defined it on Greet class.

To understand this we need to know __callStatic a PHP magic method. So if we called a static method which is not available on the class, this method will be fired by PHP for us automatically.

Consider manual Facade implementation for our Greet class; so the pattern here is if we want a ‘Facade’ for a class we would have a facade class with same name but prefixed with namespace Facades\; and in there we must have __callStatic function implemented.

So we used the core functionality of the Greet class without instantiating it.

Laravel also helps us making any class a Facade, we just have to extend it from lluminate\Support\Facades\Facade and override a function: getFacadeAccessor like so:

Greet::sayHi(‘Hi’) end up like this: (new Greet)->sayHi(‘Hi’).

So why is this important:

Let us assume we have a model called Car like this:

If you look closely you will see __callStatic method on Model class as well. Because we are extending from Model, all the things that a Model class can do, Car class can do it as well. For example we can say in our controller:

In above what it did was determined which class needs to be instantiated (proxying underlining class) and then call the create method on it by passing request data. We called a create method statically on Car class which is not present statically on Car or extending class Model, but we do have a create public method in framework source Illuminate\Database\Eloquent\Builder which the Model class is using. So we removed the need for instantiating Car class and then calling create method statically which less work and terse syntax of course :-)



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store