类范围蔓延仍然是立面带来的主要威胁

Question

我在阅读 Laravel Facades 时想到了这句话，Facade 的主要危险是类范围 Creep。这是第二段，这里是链接 https://laravel.com/docs/6.x/facades#when-to-use-facades

类范围蠕变是什么意思？

我找不到任何资源来理解类范围蔓延。

Answer 1

你的问题的答案实际上在下一句话中给出，但是，我承认在开始使用 Laravel 时我会非常困惑。所以基本上：

这意味着过多使用门面（不仅在 Laravel 中，而且在一般情况下）可能会使您的代码更加臃肿且难以阅读。 （击败了为什么你应该使用外观背后的要点）

外观还可以发展到超越其最初目的的许多事情，正如重构大师 (没有从属关系）说起来，外墙——如果使用不当——可以变成上帝对象。

如果您要使用外观并且仍然不清楚如何使用它们，我建议您阅读单一职责原则和（前面的意见）当有疑问时，不要使用外观。

示例

这部分实际上是一个“不要这样做”指南，对于快速阅读《所以，不要这样做！》的读者来说，不要这样做！

我编辑了我的答案，添加了一个以两种不同方式过度使用门面的相当荒谬的例子。

1. 您意识到外观确实解决了依赖注入模式的痛苦，谁愿意担心所有与范围、静态和特征有关的东西？所以你开始在所有事情上使用立面。需要在之前的查询中添加 where 吗？简单的！为它创建一个外观并将其命名为 Scope::where($model, $column, $equals)，想要与数据库对话，但 DB::query 刚刚开始太长？ Facades 为您提供支持，将它们放入 DataModel::longQuery() 中并在任何地方使用它们。厌倦了一直调用 ProductResource::collection 吗？将其放入名为 Resource::collection($model) 的新外观中。

2. 您添加了一个外观来帮助您生成付款链接，因此您将其称为 Payment 并最初将其与 Payment::generateLink() 一起使用，之后一段时间后，您会发现您还需要为网站内支付小部件生成视图，因此您添加了一个 Payment::view()，几个月后，当您需要与您的支付提供商讨论您的发票历史记录，只需将其添加到 Payment::getReceipts 方法中即可。您的支付外观现在是一个巨大的类，它在同一个地方处理太多不相关的事情。

在这两个示例中，您可以通过常见的编码错误清楚地看到外观的过度使用。虽然我的例子有点夸张，但我认为很容易想象这些事情如何在几个月的时间里发生在现实生活中。