Elevating Junior Laravel Developers: Learn about Contract

Reference: Viblo

Index Elevating Junior Laravel Developers series:

Continuing the series about the core parts of Laravel Framework, in this article, I will introduce the last component mentioned in the Architecture Foundations section of Laravel, besides Service Container, Service Provider, and Facade.

That is Contract.

Perhaps this will also be the last article in the Elevating Junior Laravel Developers series. Hopefully, through this series, you will have an overall view of the architecture of the Laravel Framework, as well as ponder for yourself the methods and best practices to be able to use Laravel effectively.

What is Contract?

"Contract" is just a term chosen by Taylor Otwell, the father of Laravel, as well as his colleagues as the name for a part of his framework architecture since Laravel 5.0 version, but in reality, The essence of Contract is... Interface.

This term Contract is not new or invented by Taylor, but it has been used a lot and is commonly in object-oriented programming languages, to refer to Interface or Abstract Class.

Using Interfaces will help us promote the polymorphism of object programming, which is also the key to having a well-designed system, a well-designed-application.

Use Contract

If you have reviewed and mastered Service Containers and Service Providers in your previous articles, you probably still remember that people often use Service Containers to bind an interface to an implementation. Using such an interface makes it easy to change the implementation without affecting the correctness of the program.

Here, let's recall Dependency Injection, a concept I have mentioned many times in articles in this Laravel Beauty series, to see how Contracts are being used in Laravel.

This is the example given at the end of the Facade article.

// Dependency Injection Style
class Something
{
    protected $mailer;

    public function __constructor(Illuminate\Contracts\Mail\Mailer $mailer)
    {
        $this->mailer = $mailer;
    }

    public function sendMail()
    {
        // Sending mail
        $this->mail->send($view, $data);
    }
}

As you know, Laravel, with the power of Service Container, can automatically resolve a $mailer instance for us. But the problem is that we are type-hint an Interface (Contract), not a specific class. In fact, our logic does not need to know or care about what class it is that sends mail, or how it can send mail. The only thing our logic cares about is that it needs an instance that can send mail to work. It doesn't matter which class it is an instance of, as long as that class implements the Illuminate\Contracts\Mail\Mailer interface.

In other words, our code does not depend on a specific implementation (a concrete class), but it depends on a Mailer "contract".

In addition, if you do not want to use the available Service Mailer that Laravel provides, you can write your own Service, of course, it will have to "satisfy" the "contract" (must implement the interface). Illuminate\Contracts\Mail\Mailer already. Next, we proceed to bind the Illuminate\Contracts\Mail\Mailer contract with the Service we just wrote into the Service Container, and that's it. Laravel has taken care of all the remaining work for us.

Contracts in Laravel

Contracts appear in every corner of the Laravel Framework.

On Laravel's documentation, Contracts are also described as a component that "serves as succinct documentation to the framework's features" (considered a concise set of documentation about the Framework's functions). Why, you can simply understand by looking at the Contract, we can know what the Framework (or in more specific cases, the Services of the Framework) can "do". That's what we care about (because in reality, you don't need to know how the Services "do" to perform their functions, right, unless you intend to do so. Just want to learn more to contribute to the framework)

Regarding the list of these Contracts, you can refer to the official repo illumination/contracts. There you will see how huge Laravle's contracts are

When you build your application on the Laravel platform, even though the Contracts folder is not available, you can create such a folder yourself, maybe inside the app folder, or inside folders. different, then put your Interfaces in, and make it similar to Laravel Style.

Of course, you can still create a website without knowing what a Contract is, or you find it too inconvenient to have to find where the interface you need is so you don't use it. You see you can still perform Dependency Injection even though you don't need to use Interface, but instead type-hint the specific class name, that's it. (Of course, in most cases it is a bad method)

Sometimes you can use another powerful "weapon" of Laravel that I also mentioned in the previous section, which is Facade.
Facade itself also has a close relationship with Contract. Because Facade is just a tool to hide the resolution of the service from the Service Container. That is, if you change the Contract's binding object to the Service Container, the object below the Facade (the service that the Facade resolves) will also change. You can check the Contract list, with its corresponding Facade on the Laravel documentation page, from there you will be able to know "If I don't want to use this Facade, which Contract should I use Dependency Injection with to replace, and vice versa".

Epilogue

So I have briefly introduced Contract, as well as its role in the architecture of Laravel Framework.

In fact, Contract is quite simple and easy to understand, so there really isn't much to say about it.

Contract in Laravel is simply an Interface.

If you are familiar with Service Containers and Service Providers, you may have seen the role of Interfaces before. In addition, a little basic knowledge of Object Oriented Design Principles will probably also help you understand more about the usage and importance of Interfaces.

Reference: Viblo

Thank you! Good luck! Hion Coding

Elevating Junior Laravel Developers: Learn about Contract