9

I'm currently refactoring my Zend Framework based PHP library from using a service locator to (constructor) dependency injection (DI). I feel that it improves my code a lot, but I'm not sure if I should inject all dependencies. A service locator seems easier for dependencies which are used a lot and are unspecific. I have the following dependencies which I still access using a service locator:

  1. A Zend_Translate object (I need to translate messages everywhere).
  2. A Zend_Locale object (stores the current language)
  3. A Zend_Config object (a lot of things are configurable by ini-file)
  4. Instances of utility classes (for array and string manipulation)

If I injected these dependencies, they'd clutter my constructors and distract from the specific dependencies. For testing, I can just set up these dependencies in my service locator before running the tests. The pragmatist in me says I'm doing just fine, but the purist says I should go all the way with DI.

Would you recommend DI for these types of objects or not?

markus
  • 38,729
  • 23
  • 95
  • 139
aimfeld
  • 2,508
  • 6
  • 28
  • 41
  • 3
    cannot be answered. You apparently know that there is pros and cons. It's up to you to make a conscious decision. – Gordon Mar 15 '12 at 09:47
  • Well, the question is: would you recommend DI for that or not, so the question is clear in that sense. – markus Mar 15 '12 at 09:53
  • There are very few question I upvote AND vote to close. It's an excellent question, but it seems like it's up to you to make up your mind. It's your application, and you know the pros and cons of the subject. – Madara's Ghost Mar 15 '12 at 09:57
  • 2
    @markus I'd always suggest DI over a SL any time for reasons. But that's just my opinion. Answering this is open ended and thus not a good fit for SO. Maybe it should be migrated to programmers instead. – Gordon Mar 15 '12 at 10:01
  • I'm not very familiar with what the programmers mods think to fit over there but if it fits then migration would be an option. I think it's an important question and I'd love to read peoples reasons (including yours, @Gordon). – markus Mar 15 '12 at 10:08
  • @markus mainly for the reasons outlined in http://stackoverflow.com/a/6034863/208809 – Gordon Mar 15 '12 at 10:19

1 Answers1

18

When it comes to the concern about cluttering the constructors, it's most likely a code smell that the classes are violating the Single Responsibility Principle. Constructor Injection is very beneficial here because it make this much more obvious.

Some people also worry about injecting dependencies which are only rarely used, but that's not a problem either. When it comes to creating object graphs, performance is rarely a problem, and even if it is, the Virtual Proxy pattern can fix it.

In short, there's no reason to ever use a Service Locator. There's always a better alternative that involves proper inversion of control.

Community
  • 1
  • 1
Mark Seemann
  • 209,566
  • 41
  • 390
  • 671
  • 2
    True. However, there are situations where using a Service Locator is the only way to do dependency inversion. For example, when a class is being instantiated by a third party framework that doesn't support Dependency Injection. – Enrico Campidoglio Mar 19 '12 at 22:32