Add Chapter 11

Author: JuanCrg90

README.md

@@ -11,6 +11,7 @@
 * [Chapter 8 -  Boundaries](#chapter8)
 * [Chapter 9 -  Unit Tests](#chapter9)
 * [Chapter 10 -  Classes](#chapter10)
+* [Chapter 11 -  Systems](#chapter11)
 
 
 <a name="chapter1">
@@ -1085,3 +1086,21 @@ For most systems, change is continual. Every change subjects ys to the risk that
 
 ### Isolating from Change
 Needs will change, therefore code will change. We learned in OO 101 that there are concrete classes, which contain implementation details (code), and abstract classes, which represent concepts only. A client class depending upon concrete details is at risk when those details change. We can introduce intefaces and abstract classes to help isolate the impact of those details.
+
+<a name="chapter11">
+<h1>Chapter 11 -  Systems</h1>
+</a>
+
+## Separe Constructing a System from using It
+
+*Software Systems should separate the startuo process, when the application objects are constructed and the dependencies are "wired" thogether, from the runtime logic that takes over after startup*
+
+### Separation from main
+
+One way to separate construction from use is simply to move all aspects of construction to `main`, or modules called by `main`, and to design the rest of the system assuming that all objects have been created constructed and wired up appropriately.
+
+The Abstract Factory Pattern is an option for this kind of approach.
+
+### Dependency Injection
+
+A powerful mechanism for separating construction from use is Dependency Injection (DI), the application of Inversion of control (IoC) to dependency management. Inversion of control moves secondary responsibilities from an object to other objects that are dedicated to the purpose, thereby supporting the Single Responsibility Principle. In context of dependency management, an object should not take responsibility for instantiating dependencies itself. Instead, it, should pass this responsibility to another "authoritative" mechanism, thereby inverting the control. Because setup is a global concern, this authoritative mechanism will usually be either the "main" routine or a special-purpose *container*.