Interviewers Will Ask You About This: Dependency Injection Made Simple

My heart rate was elevated and my hands were clenching the plush armrests of a very comfortable chair in a board room. He knew. After thinking about it way too long, I'd just called a singleton a factory method in a code example that was broadcast onto one of the two flat screens on the far wall. "So, what do you know about dependency injection?" Strike 2. I remembered reading something about this when I was panic studying for this interview, but I didn't really understand it. "I've... um... never used it before, but I think I understand the concept..." Sigh. This is over isn't it. Since I started teaching myself to code, one of the things that's frustrated me the most about this space, is how big all the freaking words are. Dependency Injection? What is that? What does it mean to have a dependency? What the heck is injecting it? I struggled through figuring this out so that you don't have to. The concept is not as hard as it might seem, and it can dramatically increase your code quality. If you're self-taught, this is a concept that will come up in job interviews, because in any project of a reasonable size, it is probably being used. Let's dive in, so that your interview doesn't go how mine did. What is a dependency? In short, a dependency is a piece of code that is depended upon for functionality. When we talk about dependencies, we will talk about clients and services. The client is the class that depends on something else, the class that takes the injection. The service is what is injected, it is the dependency. It's not always this clean though. Often services will also have a long list of dependencies, creating a chain of interrelated classes. But, to keep things simple for now, we'll just focus on the relationship between one client and one service. Real World Dependencies Dependencies don't only exist in your IDE. This pattern is modeled after the real world, as many concepts in object oriented programming are. If you live some distance from your workplace, it is likely that you are dependent upon a car. You are the client, and the service is your car! A dependency relationship. Let's quickly create a program that reflects this relationship. First let's create a person and give it some properties. public class Person { // Descriptors that are related to a person public string Name { get; set; } public string Workplace { get; set; } public int Age { get; set; } // A constructor for our class. public Me(string name, int age) { Name = name; Age = age } } public class Program { public static void Main(string[] args) { // An instance of Person with my information var nolan = new Person("Nolan", 27) nolan.Workplace = "Certified Angus Beef" } } Now, lets create a car, and use it to get to work! public class Car { // ... Properties public bool Drive(string destination) { Console.WriteLine($"Arrived at {destination}"); return true; } } public class Person { // ... Properties and things public void GoToWork() { // Becuase this class needs instantiated // for this behavior to work, it is a // service that Person depends on. Car car = new Car(); var hasArrived = car.Drive(Workplace); if (hasArrived) { Console.WriteLine("Made it to work!") } } } This is all a dependency is. Try looking at some of your own real world relationships and identifying the dependencies that you have. What people do you rely on? What possessions? etc. There's nothing wrong with relying on other people or things to accomplish goals and tasks, but it does become a problem when these things we rely on are the only way we know how to accomplish those goals. In this example, the only way that the Person class knows how to GoToWork is by using a Car. We have to use this implementation of Car no matter what. What if Car breaks? We can't borrow a car, or get a rental? We need to introduce more flexibility into this class. Create flexibility with interfaces I thought this was an article on dependency injection. Yes. It is. But, the concept of interfaces is tightly coupled with dependency injection...

Feb 24, 2025 - 17:54

Interviewers Will Ask You About This: Dependency Injection Made Simple

My heart rate was elevated and my hands were clenching the plush armrests of a very comfortable chair in a board room. He knew.

After thinking about it way too long, I'd just called a singleton a factory method in a code example that was broadcast onto one of the two flat screens on the far wall.

"So, what do you know about dependency injection?"

Strike 2. I remembered reading something about this when I was panic studying for this interview, but I didn't really understand it. "I've... um... never used it before, but I think I understand the concept..."

Sigh. This is over isn't it.

Since I started teaching myself to code, one of the things that's frustrated me the most about this space, is how big all the freaking words are. Dependency Injection? What is that? What does it mean to have a dependency? What the heck is injecting it?

I struggled through figuring this out so that you don't have to. The concept is not as hard as it might seem, and it can dramatically increase your code quality. If you're self-taught, this is a concept that will come up in job interviews, because in any project of a reasonable size, it is probably being used.

Let's dive in, so that your interview doesn't go how mine did.

What is a dependency?

In short, a dependency is a piece of code that is depended upon for functionality.

When we talk about dependencies, we will talk about clients and services. The client is the class that depends on something else, the class that takes the injection. The service is what is injected, it is the dependency.

It's not always this clean though. Often services will also have a long list of dependencies, creating a chain of interrelated classes. But, to keep things simple for now, we'll just focus on the relationship between one client and one service.

Real World Dependencies

Dependencies don't only exist in your IDE. This pattern is modeled after the real world, as many concepts in object oriented programming are.

If you live some distance from your workplace, it is likely that you are dependent upon a car. You are the client, and the service is your car! A dependency relationship.

Let's quickly create a program that reflects this relationship. First let's create a person and give it some properties.

public class Person
{
    // Descriptors that are related to a person
    public string Name { get; set; }
    public string Workplace { get; set; }
    public int Age { get; set; }

    // A constructor for our class.
    public Me(string name, int age)
    {
        Name = name;
        Age = age
    }
}

public class Program
{
    public static void Main(string[] args)
    {
        // An instance of Person with my information
        var nolan = new Person("Nolan", 27)
        nolan.Workplace = "Certified Angus Beef"
    }
}

Now, lets create a car, and use it to get to work!

public class Car
{
    // ... Properties

    public bool Drive(string destination)
    {
        Console.WriteLine($"Arrived at {destination}");
        return true;
    }
}

public class Person
{
    // ... Properties and things

    public void GoToWork()
    {
        // Becuase this class needs instantiated
        // for this behavior to work, it is a 
        // service that Person depends on.
        Car car = new Car();

        var hasArrived = car.Drive(Workplace);
        if (hasArrived) { Console.WriteLine("Made it to work!") }
    }
}

This is all a dependency is. Try looking at some of your own real world relationships and identifying the dependencies that you have. What people do you rely on? What possessions? etc.

There's nothing wrong with relying on other people or things to accomplish goals and tasks, but it does become a problem when these things we rely on are the only way we know how to accomplish those goals.

In this example, the only way that the Person class knows how to GoToWork is by using a Car. We have to use this implementation of Car no matter what. What if Car breaks? We can't borrow a car, or get a rental? We need to introduce more flexibility into this class.

Create flexibility with interfaces

I thought this was an article on dependency injection.

Yes. It is. But, the concept of interfaces is tightly coupled with dependency injection...