2 small questions regarding Laravel facades

Question

I know it's an issue with a lot of debate, but there are two aspects about it that I haven't seen much reference to and would like to know the answers to:

1. We're using static functions all the time - I'm sure no one will ever stop using dd() helper for example, but obviously even pure PHP static functions like json_encode() or array(). Why doesn't it make sense to see laravel classes behind facades as similar helper functions and not as class dependencies?

More than that, many times we're using those dependencies in a narrow control flow (or conditions) inside the method and the class\method is truly not necessarily dependent on those helpers all the time (for example user class used only if user is authenticated etc.)

2. In his response to this debate, Taylor Otwel himself said that the use of facades may lead to responsibility bloat in your classes meaning we might be tempted to write classes\methods that do too much and not separate them - but I don't understand how using facades instead of injecting all those classes in the contractor or method is different in terms of responsibility - from what I understand it's just a change in where you "declare" those classes - in the method signature or inside it (I understand that has a lot of differences, but don't see one in class responsibility matter). Can someone explain this?

Bottom line I'm asking this because obviously I'm all for facades when they serve as helpers and not as a core part of the class\method purpose, and I want to know I'm not the only one... I'm mostly anxious of having to write every little piece of helpers I'm using as dependencies in my classes.

Thanks!

Answer 1

Since this discussion is swathed in controversy, I'll make this short and just answer directly the two points you raised:

1. The native PHP json_encode function can be considered a helper because it's idempotent. In short, it has no dependencies, and has a predictable output. So for example the date function is not a helper function. Many people shy away from it for that reason, and use the DateTime class instead.

2. What Taylor means by responsibility bloat is that since you're not declaring your dependencies up front, you don't realize how much your controllers do. If you're forced to declare your dependencies up front (via injection), you're more likely to realize when your controller has too many dependencies, and abstract some responsibilities into their own class.

Again, note that I'm not offering an opinion here; too much controversy around it. I'm just clarifying what you've asked so that you can form your own informed opinion.