Forem: Vitor Alves

SOLID - The Letter D - Dependency Inversion Principle

Vitor Alves — Mon, 19 Apr 2021 18:07:16 +0000

The last SOLID principle is the Dependency Inversion Principle (DIP). This principle tell us that the most flexible systems use abstract dependencies instead of concrete ones. The way you achieve this is using interfaces.

What is interface?

Talking about software development, interface is a abstract type that contains no data but defines behaviours as method signatures.
For example, imagine we want to insert an account in our database:

interface AddAccountRepository {
  add: (email: String, password: String) => Account
}

You can see that the interface AddAccountRepository doesn't have an implementation, there is only a signature of the Add method. But you must be wondering: how could I use this method if there is no code?

How to implement an interface?

Imagine we would like to write the code of Add method. We have to create a new class to implement this interface.

class AccountMongoRepository implements AddAccountRepository {
}

If we write only this lines of code our IDE (Visual Studio, Eclipse, etc) will say that we must create a method called "Add". It means that when we use the word "implements" and after an interface, we have to describe and implement all the signatures of this interface. So, our code would look like this:

class AccountMongoRepository implements AddAccountRepository {
  add (email: String, password: String): Account {
  // insert an user into a MongoDb
  }
}

If we had another interface called DeleteAccountRepository.

interface DeleteAccountRepository {
  delete: (email: String) => void
}

We just have to add the interface on the "implements" part and write the delete method implementation.

class AccountMongoRepository implements AddAccountRepository, DeleteAccountRepository {
  add (email: String, password: String): Account {
  // insert an user into a MongoDb
  }

  delete (email: String): void {
  // delete an user
  }
}

Now we have an interface and a class that implements the methods of these interfaces. Now, how can we use this interface?

How to use an the implementation of an interface?

We have to inject this dependency in our class to use their implementations methods. If you want to know more about dependency injection, click here.

class DbAddAccount {
  constructor (private readonly addAccountRepository: AddAccountRepository) { }

addUser (email: String, password: String): Account {
    accountCreated = this.addAccountRepository.add(name, password)
    return accountCreated
  }
}

In the code above we see the injection of the interface AddAccountRepository. The class DbAddAccount doesn't know about the implementation about the method Add. This is important because we don't have to be aware of changes in dependencies classes.

Why is the name Dependency Inversion?

In one cenario, if we use a concrete class to insert a user into a database, the DbAddAccount class would be dependent of this class.

If we have to change our database to Postgres, for example, our class would be affected. Using the injection dependency we invert the dependency as we see in the image below.

Now DbAddAccount use AccountMongoRepository through the interface AddAccountRepository. The DbAddAccount doesn't depend on AccountMongoRepository, but on the contrary. To be used, the AccountMongoRepository depedens on DbAddAccount.

Conclusion

Dependency Inversion Principle and Dependency Injection work together. We have to use one to get the other. Although can be more difficult to understand and to code, if you use both in your code the reusability will increase, your code will be more clean and more easier for changes.

Why you should use dependency injection

Vitor Alves — Fri, 09 Apr 2021 15:22:50 +0000

As a software developer I've learned dependency injection (DI) longer than I'd like. After the first contact it was love at first sign.

In this text I'll explain some basics concept and how it will let you life easier.

First...what is a dependency?

In the world around you, a dependency is the state of existence of an entity or an item such that its stability is dictated by another entity or resource. For example, children are dependents on their parents to survive, plants are dependent on water and sunligth, and so on.

In the setting of coding, the definition of dependency shifts somewhat.

When class A uses some functionality of class B, then its said that class A has a dependency of class B. In Typescript, before we can use methods of other classes, we first need to create the object of that class. For example, you a have a controller class responsible to receive the signup request.

The SignUp controller tasks are:

Validate the fields from the request. Check if received name, email, password and password confirmation correctly.
Signup the user. Save the user data in the database.
Auth the user and send him a token.

In this example we see clearly that the signup class hast at least three dependencies. Without DI we could write our class like this:

class SignUpController{
  async handle (httpRequest: HttpRequest): Promise<HttpResponse> {
      const validation = new Validation() // First dependency
      const error = validation.validate(httpRequest.body)
      if (error) {
        .... return 400 Bad Request
      }

      const { name, email, password } = httpRequest.body

      const addAccount = new AddAccount() // Sencond dependency
      const account = await addAccount.add({ email, password, name })

      if (!account) {
        ... return 403 Forbidden
      }

      const authentication = new Authentication() // Third dependency
      const accessToken = await this.authentication.auth({ email, password })
      ...return 200 with a token JWT
  }
}

What is dependency injection?

Dependency injection is a programming technique that makes a class independent of its dependencies.

In the code above we see that the dependencies are being initialized within the method. That is not a good way to code because it became your code less easy to change (more coupling) and more difficult to test.

Instead of create the objects of another classes we could receive the objects in the constructor of the SignUp class. Hence the name: Dependency Injection. It injects the objects inside the class.

class SignUpController
    constructor (
      private readonly addAccount: AddAccount,
      private readonly validation: Validation,
      private readonly authentication: Authentication
    ) { }

    ...

}

Why does DI help with decoupling?

In the code above AddAccount, Validation and Authentication are interfaces. This allows our class to be independent of wich class will implement their respective methods. Our class don't care if we are using MongoDB or Postgres, if we are using a own class to validate or a third-party package.

So it's not necessary change our method if we decide to change some of the depencies implementation as long as it remains obeying the interface.

Why does DI help with testing?

I'll will explain this with example.

Imagine if we have to test if the method is returning 403 if the email provided is already in use.

Fisrt scenario - Not using DI

test('Should return 403 if email is already in use', async () => {
    const signUpController = new SignUpController()
    await signUpController .handle(makeFakeRequest('vitor@email.com')) // Creating the first user with the email
    const httpResponse = await signUpController.handle(makeFakeRequest('vitor@email.com')) // Trying to create the second user with the same email
    expect(httpResponse).toEqual(forbidden(new FieldInUseError('Email'))) // Expect to receive 403
})

Second scenario - Using DI

test('Should return 403 if AddAccount returns null', async () => {
    const addAccountStub = new AddAccountStub() // Creating a stub class that implements the AddAccount interface
    const signUpController = new SignUpController(addAccountStub, ...) // It has to send the others dependencies too
    jest.spyOn(addAccountStub, 'add').mockReturnValueOnce(null) // Setting a null return on the method add of the addAccountStub object
    const httpResponse = await sut.handle(makeFakeRequest('vitor@email.com')) // Creating the user with the email
    expect(httpResponse).toEqual(forbidden(new FieldInUseError('Email')))
})

In terms of quantity of code the first scenario seems to be shorter than the first. It's correct!! Using DI we have to write more code but we have more power to controll the returns of its dependencies. The main reason why DI helps to write unit test is because whe can mock the dependencies and control everything. If we are testing on method, we simply mock a return of another method to not disturb the test.

Conclusion

DI is not very easy to understand on the first glance for someone who don't use it because it's counterintuitive to write more code and increase the complexity but at the moment we start to write unit test, it is clear how important DI is. It decreases the necessity to know each detail of implementation of other classes dependencies.
It allows changes and become your code more reusable. In my point of view, DI it's essential in most cases.

Forem: Vitor Alves

SOLID - The Letter D - Dependency Inversion Principle

What is interface?

How to implement an interface?

How to use an the implementation of an interface?

Why is the name Dependency Inversion?

Conclusion

Why you should use dependency injection

First...what is a dependency?

What is dependency injection?

Why does DI help with decoupling?

Why does DI help with testing?

Conclusion

Study more