编程

Laravel 底层 - 扩展框架

544 2024-06-12 00:32:00

几天前,我正在修复一个不稳定的测试,结果发现我的工厂需要一些 uniquevalid 值。Laravel 封装了 FakerPHP,我们通常通过 fake() 助手来访问它。FakerPHP 附带了 valid()unique() 等修饰符,但你一次只能使用一个,所以不能执行 fake()->unique()->valid(),这正是我所需要的。这让我思考,如果我们想创建自己的修饰符呢?例如,uniqueAndValid() 或任何其他修饰符。我们要如何扩展框架?

思考解析

我将描述我的思路。

在进入任何过度设计的解决方案之前,我总是想检查是否有更简单的选择,并了解我正在处理的问题。所以,让我们来看看 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);
}

阅读代码,我们可以看到 Laravel 将一个单例(singleton)绑定到容器。然而,如果我们检查该 abstract,,它是一个不实现任何接口的常规类,并且对象是通过工厂创建的。这使事情变得复杂。为什么?

  1. 因为如果它是一个接口,我们可以创建一个新的类来继承基础的 \Faker\Generator 类,添加一些新功能,并将其重新绑定到容器中。但我们没有这种奢侈。
  2. 其中涉及一家工厂。这意味着它不是一个简单的实例化,有一些逻辑正在运行。在这种情况下,工厂会添加一些提供  provider(PhoneNumber, Text, UserAgent, 等)。因此,即使我们试图重新绑定,我们也必须使用工厂,该工厂将返回原始的 \Faker\Generator

有什么方案呢?有人可能会想,“是什么阻止我们创建如第 1 点所述返回 Generator 的自己的工厂,?”好吧,没有什么,我们可以做到,但我们不会!我们使用框架有几个原因,其中之一是更新。如果 FakerPHP 添加了一个新的 provider 或进行了重大升级,会发生什么?Laravel 会调整代码,没有做任何更改的人不会注意到任何东西。然而,我们会被排除在外,我们的代码甚至可能会破坏(最有可能)。所以,我们不想走那么远。

那么,我们该怎么办?

既然我们已经探索了基本的选项,我们可以开始考虑更高级的选项,比如设计模式。我们不需要一个确切的实现,只需要一些熟悉我们问题的东西。这就是为什么我总是说认识他们很好。在这种情况下,我们可以通过添加新功能来“装饰” Generator 类,同时保留旧功能。听起来不错?让我们看看怎么做!

首先,让我们创建一个新类 FakerGenerator

<?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);
    }
}

这将是我们的“装饰器”。它是一个简单的类,期望积累 Generator 作为依赖项,并引入一个新的修饰符 uniqueAndValid()。它还使用 Laravel 的 ForwardsCalls trait,这允许它代理对基本对象的调用。

此 trait 有两种方法:forwardCallToforwardDecoratedCallTo。如果要在装饰对象上链接方法,请使用后者。在我们的情况下,我们总是有一个单独的电话。

我们还需要实现 UniqueAndValidGenerator,它是自定义修饰符,但这不是本文的重点。如果您对实现感兴趣,这个类基本上是 FakerPHP 附带的 ValidGeneratorUniqueGenerator 的混合体,你可以在这里找到它。

现在,让我们在 AppServiceProvider 中扩展该框架:

<?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');
    }
}

extend() 方法检查与给定名称匹配的抽象是否已绑定到容器。如果是这样,它会用闭包的结果覆盖其值,请查看:

// Laravel: src/Illuminate/Container/Container.php

public function extend($abstract, Closure $closure)
{
    $abstract = $this->getAlias($abstract);

    if (isset($this->instances[$abstract])) {
         // You are interested here
        $this->instances[$abstract] = $closure($this->instances[$abstract], $this);

        $this->rebound($abstract);
    } else {
        $this->extenders[$abstract][] = $closure;

        if ($this->resolved($abstract)) {
            $this->rebound($abstract);
        }
    }
}(

这就是为什么我们定义了 fakerAbstractName() 方法,其产生成了 fake() 辅助方法在容器中绑定的名称相同的名称。

现在,我们每次调用 fake(), 将会返回 FakerGenerator 的实例,并且可以访问我们引入的自定义修饰符。每次我们调用 FakerGenerator 类不存在的调用,将会触发 __call(),它将使用 forwardCallTo() 方法将其代理到基类 Generator

就是这样!最终我可以这样使用 fake()->uniqueAndValid()->randomElement(),它就像一个符咒!

在结束之前,我想指出,这不是一个纯粹的装饰器模式。然而,模式并不是神圣的文本;调整它们以满足你的需求并解决问题。

结论

框架非常有用,而且 Laravel 有很多内置功能。然而,它们不能覆盖你项目中的所有边缘案例,有时你可能会陷入死胡同。当这种情况发生时,你总是可以扩展框架。我们已经看到它是多么简单,我希望你理解主要思想,它不仅仅适用于这个 Faker 例子。

总是从简单开始,寻找最简单的解决方案。必要时会出现复杂性,因此,如果基本继承起到了作用,就不需要实现装饰器或其他任何东西。当你扩展框架时,确保你不会走得太远,因为得不偿失。因为你不希望最终独自维护框架的一部分。