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

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');        

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?

  • Can you give an example of your method name giving away the dependency? It sounds like it could just be a naming problem Commented Apr 27, 2011 at 18:37

3 Answers 3


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.


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?

  • in the same way you'll remove your coupling to sarcasm - but since it was funny, no need to write a test suite
    – sunwukung
    Commented Apr 28, 2011 at 16:53

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);


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;

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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