類別範圍蔓延仍是立面帶來的主要威脅

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 方法中即可。您的支付外觀現在是一個巨大的類，它在同一個地方處理太多不相關的事情。

在這兩個範例中，您可以透過常見的編碼錯誤清楚地看到外觀的過度使用。雖然我的例子有點誇張，但我認為很容易想像這些事情如何在幾個月的時間裡發生在現實生活中。