Are service locators really that bad?

Question

People say Service Locators are bad because they expose the dependencies in some random method from the class (and not in the constructor's arguments like it should):

class A{

function F(){
   DB::query(...)
}
}

instead of

class A{
protected $db; 

function __construct(DB $db){
  $this->db = $db;
} 

function F(){
  $this->db->query(...); 
}
}

But consider a function, like imagejpeg() from GD. Obviously you can't "inject" that, so you have to call it somewhere in your class, just like your service. So isn't this the same thing? That function is a dependency too.

Or what about instantiating an object somehwere in your class methods, like PDO. Aren't these things exactly like services after all? So why all the fuss about service locators being evil?

Answer 1

The reason service locators are evil is because your class really should not be concered with any of the details of how to instantiate it's dependencies. You will end up with classes that know way too much about way too many things are get very hard to separate. Moreover, when you need to swap out that database class it is strewn about dozens of files in dozens of places rather than in a few initialization statements.

In the case of GD* functions, the way to manage that is to build an some sort of adapter interface and class that deals with calling GD* directly. Your classes talk to this interface which can easily be swapped and mocked out as you need. And need not actually be fully implemented when you are writing your main line of business code.