Dependency Injection and method signatures

Question

I've been using YADIF (yet another dependency injection framework) in a PHP/Zend app I'm working on to handle dependencies. This has achieved some notable benefits in terms of testing and decoupling classes.

However,one thing that strikes me is that despite the sleight of hand performed when using this technique, the method names impart a degree of coupling.

Probably not the best example -but these methods are distinct from ... say the PEAR Mailer. The method names themselves are a (subtle) form of coupling

//example
public function __construct($dic){
    $this->dic = $dic;
}

public function example(){
    //this line in itself indicates the YADIF origin of the DIC
    $Mail= $dic->getComponent('mail');        
    $Mail->setBodyText($body);
    $Mail->setFrom($from);        
    $Mail->setSubject($subject);
}

I could write a series of proxies/wrappers to hide these methods and thus promote decoupling from , but this seems a bit excessive. You have to balance purity with pragmatism...

How far would you go to hide the dependencies in your classes?

Answer 1

You have to couple yourself to other interfaces. If you introduce wrappers you are just coupling yourself to another interface and that is useless. What you want to avoid:

1. Having any given piece of code coupled to too many interfaces
2. Coupling a piece of code to a particular implementation.

Take the particular example of a mailer class. You obtain a reference to the mailer class. You call methods which result in an e-mail being sent. But you don't know how the e-mail is being sent. Your concerned about the fact that essentially, we can tell that you are sending an e-mail. That's whole point.

On another note, what you are doing in that example is not dependency injection. You are using the dependency injection framework to implement a service locater. In the service locator pattern, you request what you want from a particular object ($this->dic) in this case. In dependency injection the necessary components are given to the object (often in the constructor) and it doesn't have any idea where they came from.

Answer 2

Yes, you could write millions of proxies/wrappers/what-have-you (and you owe it to yourself to start doing so immediately), but you all have to name them. However, in the name of purity every conceivable and inconceivable effort is not only justified but obligating.

There are even more subtle levels of coupling. For instance the coupling to common sense. How are you going to remove that one?

Answer 3

That wouldn't be the best in term of kicking out depedencies, but you could enforce an interface. That way, your dependency will have to implement some mandatory methods.

If you use a third party library/framework I would then build an adapter that implement the same interface.

In pseudo-code :

thirdPartyClassObj = new Third_Party_Class();

adapterObj = new myAdapter(thirdPartyClassObj);

myClass(adapterObj);

In the myClass code you can check if the right methods are implemented

public function __construct($obj){
    if ($this->_isObjValid($obj) {
        $this->dic = $dic;
    } else {
        // throw an exception
    }
}

private function _isObjValid($obj) {
    if (!method_exists($obj, 'a') {
        return false;
    }
    if (!method_exists($obj, 'b') {
        return false;
    }
    return true;
}