Last week, I blogged about looking for a new application framework to use and more importantly the key things that I would want in one. After reading about the Zend framework, Symfony and Laravel and finding myself hesitant to use any one, I thought to myself why not get the best of each framework? So that's what I did.

He shows a bit of the code to get them to all play nicely together using the Zend autoloader to register the other namespaces and creating a Symfony DI container inside of the ZF Bootstrap and providing it as a resource. You can find more of the source involved in the integration on his github account.

The attitude of these pattern junkies doesn't work with me. *I* will decide whether or not I will use a particular design pattern, and *I* will decide how I implement it. This usually means that I don't use design patterns at all, and those that I do use are implemented in my own unique way. Because of this I am widely regarded as a maverick, a heretic and an outcast by those who consider themselves to be "proper" OO programmers.

Comments in the Reddit post talk about DI not being a "silver bullet", how it "empowers polymorphism" and how design patterns should not be done for the same of using design patterns

To help better explain each of the three aspects of DI I discussed in the previous article I'll be going over each more thoroughly and with those code examples requested. I'll be going through each point one at a time as the explanations will likely be of some length compared to the original post.

He starts with the "villain" of the story - the Singleton design pattern, a difficult to test method that lulls you into thinking you're not in the global scope. He talks about the problem of using this approach and how the Factory design pattern can be used to create an alternative. He changes up the example to create a "DbTableFactory" class that can be used to create the objects needed - in this case a "UserTable" object with the connection injected into it at construct time.

This article will show how we can develop software in php with a nifty design and architecture, and very much like other languages like java, using an ORM and an AOP, DI, Events container. I will assume you've read (or at least took a quick look) at this article that explains the tree layout used throughout the code, and that you have some basic knowledge of Doctrine2 and used it before on your own.

He starts with the result - an easy to use, self-contained (and decoupled) system for accessing the Doctrine2 instance. It's event-driven and uses Aspect-oriented programming to mange interactions between components (or as he calls them "beans"). Code is included for the entire process for a logger, the User entity, entity manager, user repository and transactional aspect. You can find the complete source for his example on his github account.

Dependency Injection is just a fancy term for passing dependencies to the object needing them instead of letting the object create its own. Hopefully, you've watched this great Google Clean Code talk about dependency injection by Misko Hevery where he talks about why you should ask for things instead of looking for them. I'm gonna talk about some reasons to use DI beyond just those presented in the video.

He breaks it up into a few different sections:

• It helps in the battle against global state
• It helps your design
• It makes using the single responsibility principle easier

Though in the past they enjoyed both popularity and a certain amount of prestige, without a doubt Singletons have progressively become one of the most evil and despicable villains in object-oriented design. Singletons earned their bad reputation for a reason: bringing them to life requires the programmer to deal at least with a static method. This is simply an elegant masquerade for creating a global access point (which in most cases is mutable as well) throughout an entire application. And we all know that global, mutable access is unquestionably a bad thing that must be avoided at all costs.

In this first part (of two) of the series they introduce the Singleton pattern and show how, via an example of using a database adapter interface to work with a MySQL database, in a tightly coupled example. In the second part of the series, they'll show how to break these apart using dependency injection.

If you've been watching the PHP weather vane (we call it Twitter for short), you may have noticed a shift in Symfony and Zend Framework. Version 2.0 of both web application frameworks feature Dependency Injection Containers (DICs) as the primary means of creating the objects (and even Controllers) your application will use. This is an interesting shift in a programming language that often stubbornly evaded adopting DICs to any great extent.

He introduces dependency injection (DI) as a method for "injecting" objects and configurations into other interfaces without any specific kind of relation between the two. Part of several DI implementations is a container that does some of the magic object creation for you. He applies this concept to a Zend Framework structure and talks briefly about why these containers are "the devil" because they (usually) add complexity where none is needed. He points out one container library, Pimple, that gets it right in his opinion - defining object creation as closures. In the next part of the series, he'll compare the Zend Framework's DI setup against Pimple (and Symfony's) implementations.

Whatever the reason, one of the newest concepts (at least over the past 3 years or so) that has emerged as one of our heated topics of debate is how to manage object dependencies. Interestingly, the argument of how to manage dependencies is generally named by the solution which it's proponents give as the solution: dependency injection (the abstract principle is actually called Inversion of control).

He starts with simple examples - pushing an object into the creation of another - and backfills with a brief history of dependencies in PHP applications for a little context. He talks about DI frameworks like Spring and some of the other criticisms and thoughts you'll need to consider when using DI (and DI containers) during development and deployment.

He breaks it up into two sections (really three, but he advises to ignore the third):

Introducing a parameter in to the dependency injection container's configuration
• Setting it up to allow for checks against the environment (development, production, etc)

Code samples and example XML configurations are included for both points to help make them clearer.

Working heavily with the Symfony2 Dependency Injection Container, I feel that we found some typical refactorings towards a DI container that emerge during the introduction of such a component. I want to write down the preliminary results of trying to systematize more or less as a draft. I will use the Symfony2 DI container configuration as an example but most of the refactorings should be applicable to other containers as well, some of them even to dependency injection without a container.

He's broken it up into a few different sections:

• Making a dependency explicit
• Introducing interface injection
• Exposing the service