Have you gone through the Laravel documentation and wondered where the facades are used?

What are facades?

In the image the general sparkling structure outside the building is the facade, the foundation and the building itself is behind the facade.

According to Wikipedia, the facade pattern (also spelled façade) is a software-design pattern commonly used in object-oriented programming. Analogous to a facade in architecture, a facade is an object that serves as a front-facing interface masking more complex underlying or structural code.

Or as is put in the Laravel documentation, facades provide a “static” interface to classes that are available in the application’s service container.

A facade is a class that allows static method calls to a large complicated class. Facades are mainly used in complicated framework or package classes, to expose few methods that a user actually requires. This makes for a more concise API documentation.

How do facades work?

Facades uses two classes. One is the original class that we want to provide a clean interface of, and the other is our facade class. In Laravel the facade class extends the Facade abstract class that has facade implementation for us.

Deep inside, facades use the PHP inbuilt class magic method __callStatic.

public static __callStatic(string $name ,array $arguments) : mixed

When a static method is called in a class that doesn’t define that static method, but defines the callStatic magic method, the callStatic magic method will be called instead, with the method name and the arguments passed. This allows to get an instance of the original class and call the respective required method with any of it requirements.

Usage

To illustrate how facades are used we are going to use a simple example, not very practical but illustrates the usage. 😜

We create a message collector package that we can add multiple messages in it, and it will return an array of messages, with timestamps. Not sure who wants to use though, that’s why we won’t even dive into package development since that is not in the scope of the article [or I don’t know how to😆].

1. Create the app/Utilities/MessageCollectionManager.php class

It is the implementation of the message collection functionality.

Has three methods, but the package users should only be exposed to the add and get methods. In an actual package it would have more dependencies which have to be injected every time the class is created.

2. Bind the MessageCollectionManager class into the app container

This is done inside the AppServiceProvider register method. A custom service provider can also be created then registered as a package would, but for simplicity we use AppServiceProvider.

In the app container our class is instantiated as a singleton so all the messages are collected in a single object, and the name we will use to get the singleton from the app container is “message:collector”. That could be any name preferred.

3. Create a app/Facades/MessageCollector.php

The MessageCollector class will act as if it is an independent static class with static methods. The MessageCollector class can then be in API documentation along with a few select methods that will be used by the users. But in practicality the class will extend Laravel Facade class and define the getFacadeAccessor method which will get the instance of the original MessageCollectionManager from the app container.

4. Use the MessageCollector class anywhere in the app

Example, will log the count from zero to fifty million before it starts, and after it ends.

And the output of the dump is:

Conclusion

Facades are best for very large applications developed by multiple programmers, where there is segregation and delegation of development activities or for package developers. You can also find awesome ways to use them in your applications and in that case share with us in the comments 😜


https://medium.com/@mwakalingajohn/laravel-7-datatables-net-super-tables-in-4-steps-c0b544e28bda