Return to Answer

Call to Action

Avoid static coupling of classes, or using new() on Dependencies

The key to DI-friendly code is to avoid static coupling of classes, and not to use new() for the creation of Dependencies

As others have said, Dependency Injection(DI) removes the responsibility of direct creation, and management of the lifespan, of other object instances upon which our class of interest (consumer class) is dependent (in the UML sense). These instances are instead passed to our consumer class, typically as constructor parameters or via property setters (the management of the depdencny object instancing and parameter passing is usually performed by an Inversion of Control (IoC) container, but that's another topic).

Without the DIP, code (I've called this 'consuming class') which is directly coupled to a concrete dependency is also often burdened with the responsibility of knowing how to obtain, and manage, an instance of this dependency:

Whereas after application of the DIP, the requirement is simplified to:

i.e. the coupling of the consuming class to the concrete Foo dependency has been loosened, and the concern of obtaining and managing the lifespan of the Foo dependency has been removed.

NB : The creation / mapping / projection (via new ..()) of POCO / POJO / Serialization DTOs / Entity Graphs / Anonymous Json projections et al - i.e. "Data only" classes or records - used or returned from methods are not Dependencies (in the UML sense) and not subject to DI.

As others have said, Dependency Injection(DI) removes the responsibility of direct creation, and management of the lifespan, of other object instances upon which our class of interest (consumer class) is dependent (in the UML sense). These instances are instead passed to our consumer class, typically as constructor parameters or via property setters (the management of the dependency object instancing and passing to the consumer class is usually performed by an Inversion of Control (IoC) container, but that's another topic).

Without the DIP, our code (I've called this 'consuming class') is directly coupled to a concrete dependency and is also often burdened with the responsibility of knowing how to obtain, and manage, an instance of this dependency, i.e. conceptually:

Whereas after application of the DIP, the requirement is loosened, and the concern of obtaining and managing the lifespan of the Foo dependency has been removed:

Note : The creation / mapping / projection (via new ..()) of POCO / POJO / Serialization DTOs / Entity Graphs / Anonymous JSON projections et al - i.e. "Data only" classes or records - used or returned from methods are not regarded as Dependencies (in the UML sense) and not subject to DI. Using new to project these is just fine.

As others have said, Dependency Injection(DI) removes the responsibility of direct creation, and management of the lifespan, of other object instances on which our class of interest is dependent upon (in the UML sense).

As per above example, decoupling of dependencies does require some design effort, and for the developer, there is a paradigm shift needed to break the habit of newing dependencies directly, and instead trusting the container to manage dependencies.

As others have said, Dependency Injection(DI) removes the responsibility of direct creation, and management of the lifespan, of other object instances upon which our class of interest (consumer class) is dependent (in the UML sense). These instances are instead passed to our consumer class, typically as constructor parameters or via property setters (the management of the depdencny object instancing and parameter passing is usually performed by an Inversion of Control (IoC) container, but that's another topic).

DI, DIP and SOLID

Call to Action

Avoid static coupling of classes, or using new() on Dependencies

As per above example, decoupling of dependencies does require some design effort, and for the developer, there is a paradigm shift needed to break the habit of newing dependencies directly, and instead trusting the container to manage dependencies.

But the benefits are many, especially in the ability to thoroughly test your class of interest.

NB : The creation / mapping / projection (via new ..()) of POCO / POJO / Serialization DTOs / Entity Graphs / Anonymous Json projections et al - i.e. "Data only" classes or records - used or returned from methods are not Dependencies (in the UML sense) and not subject to DI.