Laravel Under The Hood - Extension du framework

Bonjour ?

Il y a quelques jours, je réparais un test instable, et il s'est avéré que j'avais besoin de valeurs uniques et valides au sein de mon usine. Laravel enveloppe FakerPHP, auquel nous accédons habituellement via l'assistant fake(). FakerPHP est livré avec des modificateurs comme valid() et unique(), mais vous ne pouvez en utiliser qu'un seul à la fois, vous ne pouvez donc pas faire fake()->unique()->valid(), ce qui est exactement ce que je fais. nécessaire. Cela m'a fait réfléchir : et si nous voulions créer notre propre modificateur ? Par exemple, uniqueAndValid() ou tout autre modificateur. Comment pouvons-nous étendre le cadre ?

Penser à voix haute

Je vais abandonner le fil de mes pensées.

Avant de me lancer dans une solution trop sophistiquée, je veux toujours vérifier s'il existe une option plus simple et comprendre à quoi j'ai affaire. Jetons donc un coup d'œil à l'assistant fake() :

function fake($locale = null)
{
    if (app()->bound('config')) {
        $locale ??= app('config')->get('app.faker_locale');
    }

    $locale ??= 'en_US';

    $abstract = \Faker\Generator::class.':'.$locale;

    if (! app()->bound($abstract)) {
        app()->singleton($abstract, fn () => \Faker\Factory::create($locale));
    }

    return app()->make($abstract);
}

En lisant le code, nous pouvons voir que Laravel lie un singleton au conteneur. Cependant, si nous inspectons le résumé, il s'agit d'une classe normale qui n'implémente aucune interface et l'objet est créé via une usine. Cela complique les choses. Pourquoi ?

1. Parce que s'il s'agissait d'une interface, nous pourrions simplement créer une nouvelle classe qui étend la classe de base FakerGenerator, ajouter de nouvelles fonctionnalités et la relier au conteneur. Mais nous n'avons pas ce luxe.
2. Il y a une usine impliquée. Cela signifie qu'il ne s'agit pas d'une simple instanciation, mais qu'une certaine logique est exécutée. Dans ce cas, l'usine ajoute quelques fournisseurs (PhoneNumber, Text, UserAgent, etc.). Donc, même si nous essayons de relier, nous devrons utiliser l'usine, qui renverra le FakerGenerator d'origine.

Solutions ?? On pourrait se demander : « Qu'est-ce qui nous empêche de créer notre propre usine qui renvoie le nouveau générateur comme indiqué au point 1 ? » Eh bien, rien, nous pouvons faire ça, mais nous ne le ferons pas ! Nous utilisons un framework pour plusieurs raisons, l'une d'entre elles étant les mises à jour. Que se passera-t-il si FakerPHP ajoute un nouveau fournisseur ou propose une mise à niveau majeure ? Laravel ajustera le code et les personnes qui n'ont apporté aucune modification ne remarqueront rien. Cependant, nous serions exclus et notre code pourrait même se briser (très probablement). Alors oui, nous ne voulons pas aller aussi loin.

Alors, qu'est-ce qu'on fait ?

Maintenant que nous avons exploré les options de base, nous pouvons commencer à penser à des options plus avancées, comme les modèles de conception. Nous n'avons pas besoin d'une implémentation exacte, juste de quelque chose de familier avec notre problème. C'est pourquoi je dis toujours qu'il est bon de les connaître. Dans ce cas, on peut « décorer » la classe Generator en ajoutant de nouvelles fonctionnalités tout en conservant les anciennes. Ça a l'air bien? Voyons comment !

Tout d'abord, créons une nouvelle classe, FakerGenerator :

function fake($locale = null)
{
    if (app()->bound('config')) {
        $locale ??= app('config')->get('app.faker_locale');
    }

    $locale ??= 'en_US';

    $abstract = \Faker\Generator::class.':'.$locale;

    if (! app()->bound($abstract)) {
        app()->singleton($abstract, fn () => \Faker\Factory::create($locale));
    }

    return app()->make($abstract);
}

Ce sera notre "décorateur" (un peu). Il s'agit d'une classe simple qui attend le générateur de base comme dépendance et introduit un nouveau modificateur, uniqueAndValid(). Il utilise également le trait ForwardsCalls de Laravel, qui lui permet de transmettre par proxy les appels à l'objet de base.

Ce trait a deux méthodes : forwardCallTo et forwardDecoratedCallTo. Utilisez ce dernier lorsque vous souhaitez enchaîner des méthodes sur l'objet décoré. Dans notre cas, nous aurons toujours un seul appel.

Nous devons également implémenter UniqueAndValidGenerator, qui est le modificateur personnalisé, mais ce n'est pas le but de l'article. Si vous êtes intéressé par l'implémentation, cette classe est essentiellement un mélange de ValidGenerator et UniqueGenerator fournis avec FakerPHP, vous pouvez la trouver ici.

Maintenant, étendons le framework, dans l'AppServiceProvider :

<?php

namespace App\Support;

use Closure;
use Faker\Generator;
use Illuminate\Support\Traits\ForwardsCalls;

class FakerGenerator
{
    use ForwardsCalls;

    public function __construct(private readonly Generator $generator)
    {
    }

    public function uniqueAndValid(Closure $validator = null): UniqueAndValidGenerator
    {
        return new UniqueAndValidGenerator($this->generator, $validator);
    }

    public function __call($method, $parameters): mixed
    {
        return $this->forwardCallTo($this->generator, $method, $parameters);
    }
}

La méthode extend() vérifie si un résumé correspondant au nom donné a été lié au conteneur. Si c'est le cas, il remplace sa valeur par le résultat de la fermeture, jetez un oeil :

<?php

namespace App\Providers;

use Closure;
use Faker\Generator;
use App\Support\FakerGenerator;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->extend(
            $this->fakerAbstractName(), 
            fn (Generator $base) => new FakerGenerator($base)
        );
    }

    private function fakerAbstractName(): string
    {
        // This is important, it matches the name bound by the fake() helper
        return Generator::class . ':' . app('config')->get('app.faker_locale');
    }
}

C'est pourquoi nous avons défini la méthode fakerAbstractName(), qui génère le même nom que l'assistant fake() lie dans le conteneur.

Revérifiez le code ci-dessus si vous l'avez manqué, j'ai laissé un commentaire.

Désormais, chaque fois que nous appellerons fake(), une instance de FakerGenerator sera renvoyée et nous aurons accès au modificateur personnalisé que nous avons introduit. Chaque fois que nous invoquons un appel qui n'existe pas sur la classe FakerGenerator, __call() sera déclenché et il le transmettra au générateur de base en utilisant la méthode forwardCallTo().

C'est ça ! Je peux enfin faire fake()->uniqueAndValid()->randomElement(), et ça marche à merveille !

Avant de conclure, je tiens à souligner qu'il ne s'agit pas d'un pur motif de décorateur. Cependant, les modèles ne sont pas des textes sacrés ; modifiez-les pour les adapter à vos besoins et résoudre le problème.

Conclusion

Les frameworks sont incroyablement utiles et Laravel est livré avec de nombreuses fonctionnalités intégrées. Cependant, ils ne peuvent pas couvrir tous les cas extrêmes de vos projets et vous risquez parfois de vous retrouver dans une impasse. Lorsque cela se produit, vous pouvez toujours étendre le framework. Nous avons vu à quel point c'est simple, et j'espère que vous avez compris l'idée principale, qui s'applique au-delà de cet exemple Faker.

Commencez toujours par faire simple et recherchez la solution la plus simple au problème. La complexité viendra quand cela sera nécessaire, donc si l'héritage de base fait l'affaire, il n'est pas nécessaire d'implémenter un décorateur ou quoi que ce soit d'autre. Lorsque vous étendez le cadre, assurez-vous de ne pas aller trop loin, où la perte l'emporte sur le gain. Vous ne voulez pas finir par gérer vous-même une partie du framework.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!