Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Can you give an example of your method name giving away the dependency? It sounds like it could just be a naming problem –  Martijn Verburg Apr 27 '11 at 18:37
add comment

3 Answers

up vote 2 down vote accepted

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.

share|improve this answer
add comment

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?

share|improve this answer
    
in the same way you'll remove your coupling to sarcasm - but since it was funny, no need to write a test suite –  sunwukung Apr 28 '11 at 16:53
add comment

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;
}
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.