Container: Force Single Objects, Celebrate

Hey Aistis,

1. Yes, we need to be able to call all our services from the container but should worry about to instantiate them only once. We don't want to have many objects of some loader class. First of all, to have multiple objects of one class is more expensive for PHP and has performance impact. And we also can have some configuration for service, why we need to worry about to apply this configuration to the all instantiated services? So a service container is solving these things: it creates only one instance per service no matter how many time I call this service from container (if I call it 0 times - it even shouldn't be created! Good for performance!).

2. And yes, your example right! Most probably you will have a lot of different services/helpers in your project, it's a good practise to use one feature per service. And you need to teach your service container to handle, i.e. instantiate them. But there're many approaches to declare your services in service container. Here we reviewed one of them. But there're a lot of different third-party service containers, which allows to declare services in different ways. Symfony has it's own Service Container which could read service definition from different sources: YAML/XML files, PHP code, etc. which then generates the result single service container file for you.

Cheers!

So, for good practise, we must instantiate all of our service classes into one (or more) service container. We don't want to see any "New servicename()" in our code at all. That's it ?

Hey Marc R.!

That's the idea :). And you would typically only have one service container in your application. Of course, nothing is an absolute rule, but if you follow this rule, you'll be right 99%+ of the time.

Cheers!

Oh ! Even if the services do not deal with the same subjects at all ?

I thought I could group together services with common objectives and place the different containers in a specific "ServicesContainers" folder.

But if the good practice is to have only one services container, that's fine with me.

Hey Marc R.!

Yep, that's right - usually just one service container per app :). Services are "classes that do work". For example, if you created a Mailer class that sends emails, you only need to ever have one instance of this "around" in your app. If you need to send 10 emails, just get that one object and call a method on it 10 times. One of the jobs of a service container is to help you avoid creating multiple objects: you just ask it for the "mailer" and it gives you the one instance. That's nice for simplicity and performance.

To make things more complex, imagine your Mailer class's __construct method has an argument that tells it which "mail server" to send through. And sometimes, you need to send through serverA and other times serverB. In this case, you would register 2 difference services in the service container: both would use the Mailer class, but each would be passed a different argument to the constructor. You would still have one container, an the container would help make sure that you only had a maximum of one "instance" of each of the two mailer services at once.

Cheers!