3

I'm currently using Laravel and have a pretty good general grasp now on how the dependency injection and service container works now. I see it working very well when programming to interfaces, but what about concrete classes?

I utilize a service layer between my controllers and models. The point of the service objects was so that I could easily reuse their methods elsewhere, like in a different controller. But there are cases where I also need to use a service inside another service.

So I've been using the constructor for the dependency injection inside my services. The issue I kind of see is that sometimes I only need a service (inside one of my other services) for 1 method. So doing it in the constructor makes it rather large. On the other hand, since I've been setting these parameters in the constructor, I can't simply new-up an instance on demand, since it requires those parameters. For example, let's say I have an OrderService class, and for the constructor, I see two ways I can go about it:

public function __construct(FileUploadService $fileUploadService)
{
    $this->fileUploadService = $fileUploadService;
}

or

public function __construct()
{
    $this->fileUploadService = new FileUploadService;
}

I've mostly been doing it the first way, but have been thinking about the second. If I ever needed this OrderService somewhere else in the app, I can't simply create a new instance since it relies on the FileUploadService, unless I create a new instance of that too. But you can see that it will start to cascade without the dependency injection, because what if the FileUploadService depends on something also? It's just easier to resolve it out of the container.

Maybe there's something I'm missing, because it almost feels like a catch 22 in some ways. I'd like to note that a majority of these classes I'm injecting are concrete classes, so I don't need to swap them out at any particular point.

I've thought about just creating a new instance in the constructors for each service I need, that way I can also new-up the instance without providing parameters. But I like to follow best practices, so I was wondering what other experienced developers thought about this.

kenshin9
  • 2,215
  • 4
  • 23
  • 38
  • If your file upload service had constructor options, you'd start to find it painful not using dependency injection, that's if you then decide to proxy through those options in your other class's constructor. – Progrock Apr 15 '16 at 19:20
  • Exactly. So it almost seems like I should just use dependency injection for everything. But again, then there may be cases where the constructors are taking in like five dependencies. Maybe that's okay, maybe it's not. But that's what I'd like some opinions on. It's like I have to choose one or the other: using dependency injection or newing-up instances when needed. – kenshin9 Apr 15 '16 at 19:24
  • 3
    @kenshin9 I think this is more suitable for [codereview.stackexchange.com](http://codereview.stackexchange.com). I prefer injecting to avoid coupling different classes together (class A have to know how to instantiate class B). You are also able to use interfaces to allow different implementations of the dependencies to be injected without changing code throughout your app. Suggested read: http://www.phptherightway.com/#dependency_injection – JimL Apr 15 '16 at 19:33
  • Gotcha, thanks for your help and input! – kenshin9 Apr 15 '16 at 19:41
  • This might be considerably related to https://stackoverflow.com/questions/26034885/are-dao-objects-better-than-static-dao-classes-in-php – FantomX1 Sep 04 '20 at 22:40

0 Answers0