Ralph Schindler on Dependency Injection in PHP

May 19, 2011

Uncategorized

In "Learning About Dependency Injection and PHP," Ralph Schindler of Zend lays out the basic concept of Dependency Injection. Instead of just defining the concept, he explores some of the history, concerns, comparisons with other languages, and even some of the Dependency Injection Frameworks. One particular conclusion struck me as particularly important:

"It is important to realize that dependency management solutions in and of themselves are, in all the available words, full frameworks. They require that you understand both their philosophy as well have a minimal understanding of what facilities they are offering in order to use them effectively. To understand the true benefits of any framework one must first know the pain points the framework is attempting to solve."

Overall, he raises as many questions as he answers but throws in some considerations towards the future of these frameworks and how they impact the PHP world and our development practices that we use.

About Keith Casey

This should be something about myself. I've had suggestions that it should be "useful information" but I'm not sure about that.

View all posts by Keith Casey

3 Responses to “Ralph Schindler on Dependency Injection in PHP”

  1. tonymarston Says:

    It is over-complicated or the simple reason that I *NEVER* have to go through my application and change occurrences of one class for another. So why should I implement a mechanism to make this type of event easy when it’s ever going to happen?

    In the rare event that I do need to make such a change, the cost of doing it the old fashioned way is still going to be less than having this mechanism sitting there "just in case".

  2. badllama27 Says:

    The pattern described in the comment above actually says to yes this is why some level of dependency injection is good.

    $objectB = singleton::getInstance("classB");
    $result = $objectB->doStuff(…);

    This code works great, but if I have five different classes that I am loading this way over 15000 lines of code and I need to change it. I have to do a global find and replace, which isn’t that big a deal.

    The problem is what if the global find and replace misses one or has some other issue.

    I don’t trust utilities like that so I have to check all the occurences myself.

    now if I am using a dependency container.

    $objectB = $container->get("classB");
    $result = $objectB->doStuff(…);

    Looks the same, but I have a little config file that says.

    classB: MyClass

    When I update the class to something different I change the config file. Now I don’t have to worry because my class will be called handled by the container, and it implements an interface to keep all my interactions in step.

    So how is this over complicated and bad.

  3. tonymarston Says:

    This article is yet another glaring example of where OO programmers deliberately try to make a mountain out of a molehill just to prove how clever they are. To me it proves just the opposite.

    In my long career in software development I have learned to follow a number of key principles:
    a) If it ain’t broke don’t fix it.
    b) If it doesn’t cause a problem it doesn’t need a solution.
    c) Keep It Simple, Stupid!

    This "solution" is supposed to address the problem of dependencies, but what exactly is the problem? You cannot eliminate dependencies altogether as your software just would not work. If module A needs to perform some processing which is already contained within Module B then Module A simply calls Module B. This may create a dependency, but so what? It’s certainly better than having the code within Module B duplicated within Module A. This is what "Modular Programming" is all about, and Object Oriented Programming is supposed to be an extension of this paradigm by using "objects" instead of "modules".

    The idea that you need to "manage" dependencies is also ridiculous. If I have the following code in Module A:

    $objectB = singleton::getInstance("classB");
    $result = $objectB->doStuff(…);

    it is simple to understand and easy to modify. So why change to a different method which is less simple? What are the costs? What are the benefits? By introducing another layer of management you are moving towards the situation where there are too many chiefs and not enough Indians. Your application will contain a small amount of code which does useful work and a large amount of code which manages the workers. It will take longer and longer to get things done, and longer and longer to adapt to changes. And you call this "progress"? Pull the other one, it’s got bells on!

    There’s a saying in the world of aviation:

    "There are old pilots and there are bold pilots, but there are no old bold pilots"

    In the world of software development we now have:

    "There are sensible programmers and there are OO programmers, but there are no sensible OO programmers"

    When you say that "injecting dependencies is the best way to go" you forgot to add "in cloud cuckoo land". Those of us who have to live in the "real" world will continue to ignore such ridiculous concepts while still being able to write effective software.