Dependency injection: At what point am I allowed to create a new object?

Question

I am refactoring a PHP application, and I am trying to do has much dependency injection (DI) as possible.

I feel like I've got a good grasp of how it works, and I can certainly see my classes becoming a lot leaner and more robust.

I'm refactoring so that I can inject a dependency rather than create a new object within the class, but at some point I am going to have to create some objects, that is, use the dreaded new keyword.

The problem I have now run into is at what point can I actually create new objects? It's looking like I'll end up at a top level class, creating loads of new objects as there is no where else to go. This feels wrong.

I've read some blogs that use factory classes to create all the objects, and then you inject the factory into other classes. You can then call the factory methods, and the factory creates the new object for you.

My concern with doing this is now my factory classes are going to be a new free-for-all! I guess this may be OK as they are factory classes, but are there some rules to stick to when using a factory pattern and DI, or am I going way off the mark here?

Answer 1

After quite a bit of googling around for this, it seems like (as mentioned in a comment above) the top level class I was talking about is called the Composition Root.

It does indeed seem to be the accepted solution to add the creation of all objects within this Composition Root (or referencing an IoC container from here).

My original concern with this was that this top level class would end up being a bit of a mess. This is true to some extent, but the pros out weigh the cons. For example I can see the readability, testability and maintainability of all my other classes has improved.

The top level class may be a bit messy, littered with new and set_property() but I have to say I actually prefer having all this code in one place, rather than scattered about all over the other classes

Another useful page discussing performance hits of this method here

Answer 2

A Factory class will have new sprinkled throughout it. It would be creating whatever object that you are requesting and probably the dependencies of that object. Since the factories job is to instantiate the correct object for you having new in this class isn't a bad thing.

DI is so that you have a loosely-coupled design. You are able to make changes to your application by changing the dependency that is provided to each object. Making your application flexible, extensible and easy to test.

At the top level, you will have code that will instantiate a couple of factories, setup connections to services, and send a response. It will have a fair amount of new or static calls to instantiate objects that are necessary for your application. That would be where that belongs.

Answer 3

My two cents here:

I am refactoring a php application and I am trying to do has much dependency injection as possible

You don't state if you are using a dependency injection framework. I think you definitely should. Use something that gives you the features you need: https://stackoverflow.com/questions/9348376/guice-like-dependency-injection-frameworks-in-php .

The problem I have now run into is at what point can I actually create new objects? Its looking like I'll end up at a top level class, creating loads of new objects as there is no where else to go. This feels wrong.

You normally use configuration or a central point for the instantiation of the initial objects that compose your application. The container will create the objects for you.

You then access objects (services, providers, controllers...) via the IoC container. It will transparently create an object for you if needed, or give you a reference to the appropriate existing instance.

Of course, inside your particular implementation of objects you can instantiate other objects on which you don't need DI (data structures, custom types, etc), but that's normal programming.

I've read some blogs that use factory classes to create all the objects, and then you inject the factory into other classes. You can then call the factory methods, and the factory creates the new object for you.

Normally, you use a Factory if you want the IoC framework to instantiate some IoC objects through your factories (this is needed when instantiating a particular object requires some extra work). If you can simply create your objects with "new Object()", and setting some properties, you don't necessarily want to use a Factory pattern.

In other words, I'd say that using a Factory pattern for a class or group of classes depends on how you want to model those classes, not on whether you use DI (unless your DI implementation explicitly requires factories, which is unusual).

You also configure your IoC framework to use a Factory when you are using a 3rd party lib that already requires the usage of a Factory. In this case you have no control about this and you need to tell your IoC container: "hey, when I ask for one of these interfaces, you have to use this factory to provide me with an appropriate instance".

My concern with doing this is now my factory classes are going to be a new free-for-all! I guess this may be ok as they are factory classes, but are there some rules to stick to when using factory pattern and DI, or am I going way off the mark here.

In this case, it sounds that you don't need to use Factory patterns for these objects/services/controllers/whatever, and you can simply configure your IoC to instantiate with "new" the appropriate class and inject everything else.

I hope it helps.