The Dependency Injection pattern describes a solution:
Define a separate Injector object that creates and injects the objects a class requires.
A class accepts the objects it requires from an Injector object
instead of creating the objects directly.
Describing the Dependency Injection design in more detail is the theme of the following sections. See Applicability section for all problems Dependency Injection can solve. [See also MFI]

• The key idea in this pattern is to separate using objects from creating them.
  A class is no longer responsible for creating the objects it requires (uses).
  Instead, a separate injector object creates the objects and injects them into the class.
  This is also referred to as inversion of control, which is a common feature of frameworks (compare with Template Method).
• Define a separate Injector object:
  
  • The way objects are created (that is, the mapping of interfaces to implementations) is specified in separate configuration files or objects (ServiceA -> ServiceA1, ServiceB -> ServiceB1).
    
  • To let the injector do its work, classes must provide a constructor (and/or setter methods) through which the objects can be passed in (injected).
    
• A class (Client) accepts the objects it requires automatically at run-time.
  
  • A class can use objects solely through their interfaces (ServiceA,ServiceB) and doesn't have to care about how the objects are created.
  • This greatly simplifies classes and makes them easier to implement, change, test, and reuse.