21 Dependency Injection Interview Questions (ANSWERED) For Developers and Software Architects

A Dependency Injection container, sometimes, referred to as DI container or IoC container, is a framework that helps with DI. It

• creates and
• injects

dependencies for us automatically.

Dependency injection makes it easy to create loosely coupled components, which typically means that components consume functionality defined by interfaces without having any first-hand knowledge of which implementation classes are being used.

Dependency injection makes it easier to change the behaviour of an application by changing the components that implement the interfaces that define application features. It also results in components that are easier to isolate for unit testing.

Inversion of control is a broad term but for a software developer it's most commonly described as a pattern used for decoupling components and layers in the system.

For example, say your application has a text editor component and you want to provide spell checking. Your standard code would look something like this:

public class TextEditor {

    private SpellChecker checker;

    public TextEditor() {
        this.checker = new SpellChecker();
    }
}

What we've done here creates a dependency between the TextEditor and the SpellChecker. In an IoC scenario we would instead do something like this:

public class TextEditor {

    private IocSpellChecker checker;

    public TextEditor(IocSpellChecker checker) {
        this.checker = checker;
    }
}

You have inverted control by handing the responsibility of instantiating the spell checker from the TextEditor class to the caller.

SpellChecker sc = new SpellChecker; // dependency
TextEditor textEditor = new TextEditor(sc);

When we register services in a container, we need to set the lifetime that we want to use. The service lifetime controls how long a result object will live after it has been created by the container.

There are three lifetimes that can be used with Microsoft Dependency Injection Container, they are:

• Transient — Services are created each time they are requested. It gets a new instance of the injected object, on each request of this object. For each time you inject this object is injected in the class, it will create a new instance.
• Scoped — Services are created on each request (once per request). This is most recommended for WEB applications. So for example, if during a request you use the same dependency injection, in many places, you will use the same instance of that object, it will make reference to the same memory allocation.
• Singleton — Services are created once for the lifetime of the application. It uses the same instance for the whole application.

Single responsibility is the concept of a Class doing one specific thing (responsibility) and not trying to do more than it should, which is also referred to as High Cohesion.

Classes don't often start out with Low Cohesion, but typically after several releases and different developers adding onto them, suddenly you'll notice that it became a monster or God class as some call it. So the class should be refactored.

Scoped lifetime actually means that within a created “scope” objects will be the same instance. It just so happens that within .Net Core, it wraps a request within a “scope”, but you can actually create scopes manually. For example :

Consider:

public void ConfigureServices(IServiceCollection services)
{
	services.AddScoped<IMyScopedService, MyScopedService>();
	var serviceProvider = services.BuildServiceProvider();
	var serviceScopeFactory = serviceProvider.GetRequiredService<IServiceScopeFactory>();
	IMyScopedService scopedOne;
	IMyScopedService scopedTwo;
	using (var scope = serviceScopeFactory.CreateScope())
	{
		scopedOne = scope.ServiceProvider.GetService<IMyScopedService>();
	}
	using (var scope = serviceScopeFactory.CreateScope())
	{
		scopedTwo = scope.ServiceProvider.GetService<IMyScopedService>();
	}

	Debug.Assert(scopedOne != scopedTwo);
}

In this example, the two scoped objects aren’t the same because created each object within their own scope.

Dependency injection is basically providing the objects that an object needs (its dependencies) instead of having it construct them itself. When using dependency injection, objects are given their dependencies at run time rather than compile time (car manufacturing time).

• It allows your code to be more loosely coupled because classes do not have hard-coded dependencies
• Decoupling the creation of an object (in other words, separate usage from the creation of an object)
• Making isolation in unit testing possible/easy. It is harder to isolate components in unit testing without dependency injection.
• Explicitly defining dependencies of a class
• Facilitating good design like the single responsibility principle (SRP) for example
• Promotes Code to an interface, not to implementation principle
• Enabling switching/ability to replace dependencies/implementations quickly (DbLogger instead of ConsoleLogger for example)

S.O.L.I.D is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin.

• S - Single-responsiblity principle. A class should have one and only one reason to change, meaning that a class should have only one job.
• O - Open-closed principle. Objects or entities should be open for extension, but closed for modification.
• L - Liskov substitution principle. Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.
• I - Interface segregation principle. A client should never be forced to implement an interface that it doesn't use or clients shouldn't be forced to depend on methods they do not use.
• D - Dependency Inversion Principle. Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.

Coding against interface means, the client code always holds an Interface object which is supplied by a factory.

Any instance returned by the factory would be of type Interface which any factory candidate class must have implemented. This way the client program is not worried about implementation and the interface signature determines what all operations can be done.

This approach can be used to change the behavior of a program at run-time. It also helps you to write far better programs from the maintenance point of view.

The Inversion-of-Control (IoC) pattern, is about providing any kind of callback (which "implements" and/or controls reaction), instead of acting ourselves directly (in other words, inversion and/or redirecting control to the external handler/controller).

For example, rather than having the application call the implementations provided by a library (also know as toolkit), a framework calls the implementations provided by the application.

The Dependency-Injection (DI) pattern is a more specific version of IoC pattern, where implementations are passed into an object through constructors/setters/service lookups, which the object will 'depend' on in order to behave correctly.

Every DI implementation can be considered IoC, but one should not call it IoC, because implementing Dependency-Injection is harder than callback (Don't lower your product's worth by using the general term "IoC" instead).

• IoC without using DI, for example, would be the Template pattern because the implementation can only be changed through sub-classing.
• DI frameworks are designed to make use of DI and can define interfaces (or Annotations in Java) to make it easy to pass in the implementations.
• IoC containers are DI frameworks that can work outside of the programming language. In some, you can configure which implementations to use in metadata files (e.g. XML) which are less invasive.

If a system exhibits any or all of the following three traits then we have identified bad design:

• the system is rigid: it’s hard to change a part of the system without affecting too many other parts of the system
• the system is fragile: when making a change, unexpected parts of the system break
• the system or component is immobile: it is hard to reuse it in another application because it cannot be disentangled from the current application.

The Inversion-of-Control (IoC) pattern, is about providing any kind of callback (which controls reaction), instead of acting ourself directly (in other words, inversion and/or redirecting control to the external handler/controller).

Inversion of Controls is also about separating concerns.

• Without IoC: You have a laptop computer and you accidentally break the screen. And darn, you find the same model laptop screen is nowhere in the market. So you're stuck.

• With IoC: You have a desktop computer and you accidentally break the screen. You find you can just grab almost any desktop monitor from the market, and it works well with your desktop.

Your desktop successfully implements IoC in this case. It accepts a variety type of monitors, while the laptop does not, it needs a specific screen to get fixed.

Compare this:

var svc = new ShippingService(new ProductLocator(), 
   new PricingService(), new InventoryService(), 
   new TrackingRepository(new ConfigProvider()), 
   new Logger(new EmailLogger(new ConfigProvider())));

over this:

var svc = IoC.Resolve<IShippingService>();

Your dependencies chain can become nested, and it quickly becomes unwieldy to wire them up manually. Even with factories, the duplication of your code is just not worth it.