Class creep remains the main threat posed by facades

Question

I thought of this quote while reading Laravel Facades , The main danger of Facade is class scope Creep. This is the second paragraph, here is the link https://laravel.com/docs/6.x/facades#when-to-use-facades

Class scope creepWhat does it mean?

I can't find any resources to understand class scope creep.

Answer 1

The answer to your question is actually given in the next sentence, however, I admit that I get very confused when starting to use Laravel. So basically:

This means that using facades too much (not just in Laravel, but in general) can make your code more bloated and difficult to read. (beats the point behind why you should use facades)

Facades can also evolve into many things beyond their original purpose, and as Remodeling Guru (no affiliation) puts it, facades - if used incorrectly - can become gods Object. p>

If you are going to use facades and still don't know how to use them, I recommend reading Single Responsibility Principle and (previous comment) When in doubt, don't use facades.

Example

This section is actually a "Don't Do This" guide, for a quick read of "So, Don't Do This!" ” readers, don’t do this!

I edited my answer to add a rather ridiculous example of overuse of facade in two different ways.

1. You realize that facades really solve the pain of dependency injection patterns, who wants to worry about all that stuff with scopes, statics, and traits? So you start using facades on everything. Do I need to add where to the previous query? simple! Create a look for it and name it Scope::where($model, $column, $equals), want to talk to the database, but DB::query is just getting started Too long? Facades provide support for you, put them into DataModel::longQuery() and use them everywhere. Tired of calling ProductResource::collection all the time? Put it into a new skin called Resource::collection($model).

2. You added a facade to help you generate payment links, so you called it Payment and initially used it with Payment::generateLink() , after some time you will find that you also need to generate a view for the in-site payment widget, so you add a Payment::view(), and a few months later, when you need to generate a view with your The payment provider discusses your invoice history, just add it to the Payment::getReceipts method. Your payment facade is now one giant class that handles too many unrelated things in the same place.

In both examples, you can clearly see the overuse of looks through common coding mistakes. While my examples are a bit exaggerated, I think it's easy to imagine how these things could happen in real life over the course of a few months.