Symfony Dependency Injection and Lazy Services

We are using Symfony’s DependencyInjection component, but, we aren’t using the full-stack framework. In fact, the only other Symfony component we currently use is Doctrine.

When I attempted to utilize lazy Services, I installed the symfony/proxy-manager-bridge package as instructed. Since it is a dependency, this also installed the ocramius/proxy-manager package. However, lazy Services still weren’t working. It ends up that I needed to tell the ContainerBuilder which ProxyInstantiator to use:

The RuntimeInstantiator is installed as part of the proxy-manager-bridge, but, I guess it isn’t utilized automatically unless you’re using the full-stack framework. If you don’t tell it to use the RuntimeInstantiator, it will fallback to using the default RealServiceInstantiator.

Anyway, nothing too complex here, but, I had trouble finding anything online, so I figured I’d put this together so that it might help someone else in the future.

Dependency Injection vs Encapsulation?

Let me start by saying that I LOVE the concept of dependency injection (DI) and feel that it should be utilized as much as possible. However, it seems to be somewhat contradictory to a concept that was drilled into me starting with my first programming classes: encapsulation.

Let me illustrate the conflict with an example. Proper DI techniques say that you should create your classes along these lines:

Where this seems to go against the concepts of encapsulation, is the fact that instances of Bar and Baz now have to exist outside of the Foo class. If interaction with those classes is not needed outside of the Foo class, wouldn’t it be better to hide it’s existence all together?

The example above might seem a bit trivial, but what if the creation of a Bar instance was very complex, but still requires nothing outside of the Foo class in order to create it?

Am I missing something? Even if they are conflicting paradigms, I think DI is the better option, but are they really conflicting?