The Dependency Injection design pattern solves problems like:
How can a class be independent of how the objects it requires are created?
How can the way objects are created be specified in separate configuration files?
See Applicability section for all problems Dependency Injection can solve. See Solution section for how Dependency Injection solves the problems.

• An inflexible way is to create objects (new ServiceA1(), new ServiceB1()) directly within the class (Client) that requires (uses) the objects.
• This commits (couples) the class to particular objects and makes it impossible to change the instantiation later independently from (without having to change) the class. It stops the class from being reusable if other objects are required, and it makes the class hard to test because real objects can't be replaced with mock objects.
  Furthermore, a class often requires objects that have further de­pendencies, which in turn have de­pen­dencies, and so on, which results in having to create a complex object structure manually.
• That's the kind of approach to avoid if we want that a class is independent of how its objects are created.
• For example, designing reusable classes that require (depend on) other objects.
  A reusable class should avoid creating the objects it requires directly (and often it doesn't know at compile-time which class to instantiate) so that it can accept the objects it requires at run-time (from an injector object).
• For example, supporting different configurations of an application.
  Instantiating concrete classes throughout an application should be avoided so that the way objects are created can be specified in separate (external) configuration files.