Laravel 底层 - 扩展框架

几天前，我正在修复一个不稳定的测试，结果发现我的工厂需要一些 unique 和 valid 值。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 有两种方法：forwardCallTo 和 forwardDecoratedCallTo。如果要在装饰对象上链接方法，请使用后者。在我们的情况下，我们总是有一个单独的电话。

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

现在，让我们在 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 例子。

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