As Zend Framework 2 is well and truly here, before some of us who are new to it dive right on in, whether you’re completely new or, like me, migrating from Zend Framework 1, it’s really important to ensure that we understand the core concepts on which it’s based.
Like anything that you want to know well, knowing the core concepts will help you become a master quicker, because you have a more informed understanding of what you’re working with, how it’s composed, the paradigms and methodology it’s built around (and consequently will be most suited to building applications with) and so on.
So this series will be covering those essentials. It’s not going to be going too heavy in to code, more looking at understanding the concepts themselves. Though there will be code, as needed.
The ones that I’ll be looking at in this series are:
- Dependency Injection
- Modules (Module Manager)
- Events (Event Manager)
- Services (Service Manager)
In this, the first part in the series, I’m going to go through what dependency injection (DI) is. However, as there are a number of great posts already available on the topic by some very experienced developers, including Pádraic Brady, Ralph Schindler and Zend Framework project lead, Matthew Weier O’Phinney, I’m not going to rehash them.
Instead, below I’ve included 5 of the best quotes available. My aim is so that you can see a series of different perspectives from some really experienced and educated people on what dependency injection is and get abreast of it quickly.
All references contain their respective Urls, which are also included in the further reading section of the post. I encourage you to read the respective posts from which they’re taken, as they provide excellent depth and understanding.
Matthew Weier O’Phinney
Dependency Injection is like ordering off the menu — but specifying things like, “I’d like to substitute portabella mushrooms for the patties, please.” The waiter then goes and brings your dish, which has portabella mushrooms instead of the hamburger patties listed on the menu.
Zend Framework 2 Manual
In it’s simplest form, a Dependency Injection Container (here-in called a DiC for brevity), is an object that is capable of creating objects on request and managing the “wiring”, or the injection of required dependencies, for those requested objects. Since the patterns that developers employ in writing DI capable code vary, DiC’s are generally either in the form of smallish objects that suit a very specific pattern, or larger DiC frameworks.
> The basic idea of the Dependency Injection is to have a separate object, an assembler, that populates a field in the lister class with an appropriate implementation for the finder interface, resulting in a dependency diagram along the lines of Figure 2 >
Dependency injection is a software design pattern that allows a choice of component to be made at run-time rather than compile time. This can be used, for example, as a simple way to load plugins dynamically or to choose mock objects in test environments vs. real objects in production environments.
This software design pattern injects the depended-on element (object or value etc) to the destination automatically by knowing the requirement of the destination.
Pico Container Website (via Fabian Potencier)
Dependency Injection is where components are given their dependencies through their constructors, methods, or directly into fields.
Dependency injection means giving an object its instance variables. Really. That’s it.
So there you have it – 6 great perspectives on dependency injection. I hope that in preparation for using Zend Framework 2 (and further software development generally), this post has helped you better understand one of its key concepts.
What are your thoughts on DI? Share them with me in the comments. I’m keen to know what you think. Stay tuned next week for the next part of the series – Zend\ModuleManager.
Don’t miss the next post. Drop your email in the box below, and get it straight to your inbox, PLUS exclusive content only available by email. No spam, and you can unsubscribe at any time.