title: Using dependency injection over laravel facades
body: <p>I have read a number of sources that hint that laravel facade's ultimately exist for convenience and that these classes should instead be <a href="https://stackoverflow.com/a/33465977/817379">injected</a> to allow loose coupling. Even <a href="https://phpnews.io/feeditem/response-don-t-use-facades" rel="noreferrer">Taylor Otwell has a post</a> explaining how to do this. It seems I am not the only one to <a href="https://stackoverflow.com/questions/27080739/laravel-should-all-the-classes-be-injected-through-constructor">wonder this</a>.</p>
  
  <pre><code>use Redirect;
  
  class Example class
  {
      public function example()
      {
           return Redirect::route("route.name");
      }
  }
  </code></pre>
  
  <p>would become </p>
  
  <pre><code>use Illuminate\Routing\Redirector as Redirect;
  
  class Example class
  {
      protected $redirect;
  
      public function __constructor(Redirect $redirect)
      {
          $this-&gt;redirect = $redirect
      }
  
      public function example()
      {
           return $this-&gt;redirect-&gt;route("route.name");
      }
  }
  </code></pre>
  
  <p>This is fine except that I am starting to find that some constructors and methods are beginning to take four+ parameters. </p>
  
  <p>Since the Laravel IoC <em>seems</em> to only inject into class constructors and certain methods (controllers), even when I have fairly lean functions and classes, I am finding that constructors of the classes are becoming packed out with the needed classes that then get injected into the needed methods.</p>
  
  <p>Now I am finding that if I continue down this approach that I will need my own IoC container, which feels like reinventing the wheel if I am using a framework like laravel?</p>
  
  <p>For example I use services to control the business / view logic rather than controllers dealing with them - they simply route the views. So a controller will first take its corresponding <code>service</code>, then then the <code>parameter</code> in its url. One service function also needs to check the values from a form, so then I need <code>Request</code> and <code>Validator</code>. Just like that, I have four parameters.</p>
  
  <pre><code>// MyServiceInterface is binded using the laravel container
  use Interfaces\MyServiceInterface;
  use Illuminate\Http\Request;
  use Illuminate\Validation\Factory as Validator;
  
  ...
  
  public function exampleController(MyServiceInterface $my_service, Request $request, Validator $validator, $user_id) 
  { 
      // Call some method in the service to do complex validation
      $validation = $my_service-&gt;doValidation($request, $validator);
  
      // Also return the view information
      $viewinfo = $my_service-&gt;getViewInfo($user_id);
  
      if ($validation === 'ok') {
          return view("some_view", ['view_info'=&gt;$viewinfo]);
      } else {
          return view("another_view", ['view_info'=&gt;$viewinfo]);
      }
  }
  </code></pre>
  
  <p>This is a single example. In reality, many of my constructors already have multiple classes being injected (Models, Services, Parameters, Facades). I have started to 'offload' the constructor injection (when applicable) to method injection, and have the classes calling those methods use their constructors to inject dependencies instead.</p>
  
  <p>I have been told that more than four parameters for a method or class constructor as a rule of thumb is bad practice / code smell. However I cannot see how you can really avoid this if you choose the path of injecting laravel facades.</p>
  
  <p>Have I got this idea wrong? Are my classes / functions not lean enough? Am I missing the point of laravels container or do I really need to think of creating my own IoC container? <a href="https://stackoverflow.com/questions/15824673/laravel-dependency-injection-and-the-ioc-container">Some</a> others <a href="https://stackoverflow.com/a/25915119/817379">answers</a> seems to hint at the laravel container being able to eliminate my issue? </p>
  
  <p>That said, there doesn't seem to be a definitive consensus on the issue...</p>