refactor(injection_types): refactoring on disadvantages

Guikingone · Guikingone · commit af46b4f10d70 · 2019-04-03T14:48:31.000+02:00
Refactoring on disadvantages for setter and immutable setter.
diff --git a/service_container/injection_types.rst b/service_container/injection_types.rst
@@ -191,8 +191,11 @@ so, here's the advantages of immutable-setters:
 * Your service becomes immutable, as the container will return a new object,
   the initial service stays clean and unchanged.
 
-* You can easily change the injected service as long as it respect the interface/type
-  asked by the initial service.
+* This type of injection works well with traits as the service can be composed,
+  this way, adapting the service to your application requirements is easier.
+
+* The setter can be called multiple times, this way, adding a dependency to a collection
+  becomes easier and allows you to add a variable number of dependencies.
 
 The disadvantages are:
 
@@ -204,8 +207,8 @@ The disadvantages are:
   you can found that adding docblock for a single method isn't adapted or
   link your code to the container.
 
-* As this approach force the container to create a new object
-  once the method is called, you can found hard to debug and test your code.
+* Unless the service is declared lazy, it is incompatible with services
+  that reference each other in what are called circular loops
 
 Setter Injection
 ----------------
@@ -278,6 +281,9 @@ This time the advantages are:
   the method adds the dependency to a collection. You can then have a variable
   number of dependencies.
 
+* Like the immutable-setter one, this type of injection works well with
+  traits and allows you to compose your service.
+
 The disadvantages of setter injection are:
 
 * The setter can be called more than just at the time of construction so
