DIP — The Dependency Inversion Principle

The Dependency Inversion Principle is a part of SOLID, a mnemonic acronym that bundles a total of 5 design principles.

It is often associated with clean code.

But what exactly is it, is it important to you, should you even care?

What does it state?

Modules that encapsulate high-level policy should not depend upon modules that implement details. Rather, both kinds of modules should depend upon abstractions.

This may sound a little complicated, but you can break it up, as follows:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces).
2. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

Still not better?

Okay, view it this way:

Don’t let anything you build depend on a concrete implementation of something. Better depend on an abstract description of a contract and let any implementor decide how to satisfy that contract.

An Example

Looking at examples can usually help to understand a concept better, so here’s one.

What you see here is one way of structuring a backend API. A resource layer that implements the specifics of the API, a service that contains the business logic, and repositories that handle the persistence layer (e.g. database interactions).

class PositionRepository {
  constructor() {}
}
class TransactionRepository {
  constructor() {}
}
class TransactionService {
  private readonly transactionRepository: TransactionRepository;
  private readonly positionRepository: PositionRepository;
  constructor(
    transactionRepository: TransactionRepository,
    positionRepository: PositionRepository
  ) {
    this.transactionRepository = transactionRepository;
    this.positionRepository = positionRepository;
  }
}
class TransactionResource {
  private readonly transactionService: TransactionService;
  constructor(transactionService: TransactionService) {…