DEV Community: Yuto

What is the Dependency Inversion Principle?

Yuto — Sun, 27 Sep 2026 22:55:20 +0000

I recently encountered this principle while I was learning modern server-side design in Node.js and found out that this is one of the core concepts of the SOLID Principles.

I'm going to explain the Dependency Inversion Principle in short.

In a nutshell, the Dependency Inversion Principle (a.k.a. DIP) says

High-level logic should not depend on low-level modules. Both should depend on abstraction.

Abstraction must not depend on the details, but details should depend on abstraction.

The first time I saw this explanation, that was all jargon. Absolutely rocket science.

Houston, we have a problem.

The longer I invested my time, the clearer my understanding became.

Dependency Inversion Principle

If I picture the Dependency Inversion Principle, it would be like this image.

Take a look at the left side of the image; the Low-Level Module depends on the High-Level Module.
However, the right side shows both Modules depend on the Abstraction ( an Interface). Our goal is the right side.

The module uses other modules with "import" and "use" called the Low-Level Module.

Let's dive into more details.

On top of this layer, the Presentation layer is responsible for UI needs and must be flexible because it changes often. On the other hand, a domain layer, which represents business logic, doesn't have to be the same.

The domain layer must be the most stable.

If there is a dependency between the modules, the dependent side will have lower stability and higher flexibility. This is because as you import more modules, the code becomes more complex. On the other hand, the one being depended upon will have higher stability and lower flexibility.

You have to avoid importing other modules as much as you can in the domain layer; otherwise, your application gets lower stability.

Example codes

// Infrastructure/CarRepository.ts

export class CarRepository { 
  constructor(private model: string) {}

  start() {
    console.log(`Starting ${this.model}`);
  }
}

// Domain/Car.ts

import { CarRepository } from "../Infrastructure/CarRepository";

class Car {
  private carRepository: CarRepository;

  constructor(private model: string) {
    this.carRepository = new CarRepository(model);
  }

  startEngine() {
    this.carRepository.start();
  }
}

const car = new Car('Toyota')
car.startEngine()

This code violates DIP. "Domain/Car.ts" depends on Infrastructure/CarRepository.ts and imports the CarRepository class from the infrastructure layer.

How can we achieve DIP? The steps are like this below

Create an interface for CarRepository (We name it ICarRepository)
Implement CarRepository by implementing that interface
Make the Car class dependent on that interface.

Steps 1 and 2

// Domain/Car.ts

import { CarRepository} from "../Infrastructure/CarRepository";

// Creating an interface
export interface ICarRepository { 
  start(): void;
}

class Car {

  // Receiving carRepository
  constructor(private carRepository: ICarRepository) {
    this.carRepository = carRepository;
  }
  startEngine() {
  // Using the carRepository you received 
    this.carRepository.start();
  }
}

Using Dependency Injection (a.k.a. DI)

Get rid of the declaration of carRepository from the domain layer.
Create an interface for CarRepository.

Now, the constructor takes an instance of ICarRepository and assigns it to the carRepository.

Step 3

// Infrastructure/CarRepository.ts

import { ICarRepository } from "../Domain/Car";

export class CarRepository implements ICarRepository { 
  constructor(private model: string) {}

  start() {
    console.log(`Starting ${this.model}`);
  }
}

Using the interface to define CarRepository.

// main

const carRepository = new CarRepository('Toyota');
const car = new Car(carRepository);
car.startEngine();

Creating a new Car instance. The carRepository is passed as a parameter. This demonstrates Dependency Injection, where the Car class receives the repository it should work with.

In this case, the Domain layer is independent of the Infrastructure layer; however, the Infrastructure layer depends on the Domain layer.

Conclusion

This is called Dependency Inversion. If there is a change in the Infrastructure layer, it doesn't affect the Domain layer.
In other words, business logic is independent of the choice of technologies. It allows you to make a robust application.

Using Array.at() over Array[index]

Yuto — Sun, 19 Jan 2025 05:11:07 +0000

In this article, I'll talk about why we might want to use Array.prototype.at() over Array[index] when accessing elements of an array.

Motivation

When accessing elements of an array, I used to use Array[index], similar to Array[1].
This is what I have been familiar with and what I learned when grabbing an element.

However, I recently received a code review from one of my coworkers, who said "Why don't you use Array.prototype.at() instead of relying on the index?"

My code was

const element = arr[1]

and he suggested

const element = arr.at(1)

This way was eye-opening to me because it looked pretty straightforward.

How to use Array.prototype.at()

Let me introduce you to what Array.prototype.at() is capable of.

It takes an integer and returns an element of an array.

For instance, you have an array

const arr = ["One", "Two", "Three"]

Then you call

arr.at(0) // returns "One"

That's straightforward.

It's equivalent to bracket notation, array[0]. You might wonder what's the deal. We are going to dive into the benefits of using this method.

Why Array[index] is not ideal?

Let's take a look at a couple of situations where we might want to use Array.prototype.at() method instead of Array[index].

Getting the last element of an array.

Suppose you have an array of strings such as

const sports = ["basketball", "baseball", "football"]
and when you want to pick up the last element of this array, "football" in this case you could write this code.

const lastElement = sports[sports.length - 1]

This is the correct way; however, you can write differently with Array.prototype.at() method.

const lastElment = sports.at(-1)

Don't you think it's way readable?

Type inference

In TypeScript, bracket notation doesn't give a possibility of being undefined.

const arr:string[] = []
const element = arr[0]
console.log(element) // undefined

The value, element is typed as string not string | undefined.

We expect TypeScript to give a compile error while writing code.

In general, we want to ensure the array has an element we try to access.

const arr:string[] = []
const element = arr[0]
if(typeof element === 'string') console.log(element)

Weirdly, we are checking the element's type that TypeScript infers as string.

As you might wonder, we can do type assertions like

const element : string | undefined = arr[0]

however, this is the last thing we want to do because we don't have to assume ourselves writing the perfect code.

To solve this problem, we can do two things.

Write a type-guard function
Use noUncheckedIndexedAccess

noUncheckedIndexedAccess

Both ways work well but if you use Array.prototype.at(), you don't; have do both of them.

const arr:string[] = []
const element = arr.at(0) // string | undefined
console.log(element)

If you try to insert the value element to other values that typed as string, you'd get a compile error

const arrOfFruit = ["Apple", "Banana", "Grape"]
const arr:string[] = []
const element = arr.at(0)

arrOfFruit.includes(element)

Type 'string | undefined' is not assignable to type 'string'.
  Type 'undefined' is not assignable to type 'string'.

Conclusion

You can write more straightforward code with Array.prototype.at() and avoid putting extra functions and configs.

Array.prototype.at() explained in mozilla