When can Dependency Injection Containers become too big, and what can I do about it?

Question

We all know the why Dependency Injection is awesome because it makes code less coupled, easier to test, and much nicer to read! And then some decide to use a

Answer 1

Let's say that all of your classes are going to be called via the DI container.

First a little comparative case: If you go to a store to buy a pair of trousers, then you are using DI at several moments. For instance you do not have to tell what size you need, the people that help you have the expertise to find out. You will have to say what kind of type of trousers you want to have, the people of the store will present you some trousers according to your wishes (or let you know that that is impossible). An example which is not DI is the answer to the question where all those trousers come from. For a customer entering the store is the answer to that question totally irrelevant. It will never be the reason to enter the shop, where the need for a pair of trousers of a certain type is. You can ask unspecified questions of a certain type and you will get exact answers. That is the core of DI. How it is done is not of your business nor your concern. But you can not ask anything. You can't buy bread in a cloth store for instance. The questions must be related to the specific DI subject (interface).

Pimple is an associative array. It is not a DI - container. As far as you know, will the DI - container return an interface, where the DI - container knows which implementation to load. Let me give you an example to show you where Pimple is not a DI - container. You are in the store, you have chosen a pair of trousers and you want to buy it. Now you are going to pay. How? That is DI again. For you it is no problem, you have several methods for the transaction available and you will choose one. How the system will answer is not interesting for you: you will say nothing, just get your wallet and start paying.

In Pimple you will have to select the object to use for payments. The client will have to say 'I need the payment object'. In a true DI - container will you just have to hand over the money in a legal way (interface behavior) and based on the input data will the DI - container know which implementation to choose (cash, credit card, master card). You do not have to worry about that. If you still would have to worry about that, why call it dependency injection? Pimple is at his best a service locator, but to use DI you will have to use an interface. Otherwise is there nothing to hide, no dependency to inject. :-)

So, don't use Pimple for DI. It is not a DI - container. If you are going to use Pimple (and it can organize your classes well) then do not call it DI. It is at its best a service locator, but it is not hiding the implementation using interfaces. Hence it can not be DI.

Try to organize your codebase. What are the functions of the different classes? Which classes need DI? I suggest you only use DI for classes that execute functional requirements. When you go back to the case of the store: all functions in which the store personnel is communicating with the client directly. Not for the implementation how to walk to the back end trying to find another pair of trousers. Not for the process how to open or close the shop. But yes for how to welcome a client and asking what type of trousers someone wants to have. In your application: are there interfaces/classes which are used directly interacting with the visitors of the application and could you create some type of contract how to describe the interaction? That is the design of that DI - container. I would not use DI all over the place. DI comes with a performance penalty and a maintenance problem. The more DI you use, the more layers you will have, the less you will know what happens where. Use DI preferrably where it is most beneficial and that is where it is most likely that the implementation will change yet the caller will not know that the interface has changed nor is the caller interested in such a change. If you take that as a guideline, then can you make distinctions which classes to hide via a DI - container and which classes not.