DEV Community: Murilo Maia

Dependency inversion explained

Murilo Maia — Mon, 01 Nov 2021 23:02:22 +0000

When we start to programming, it's usual to develop simple algorithms. Who has never created a CRUD of users? Althought, as time goes by, our knowledge increases and our challenges too.
Now, imagine that you are developing an application where everytime the user creates his account or forget his password, the system sends to him an email. As you are getting started, you choose to use the easiest and cheaper way to send emails: using SMTP.

I'm going to use Typescript in example but you can use any oriented object language.

As said before, our imaginary application will send email when the user register and forgot password. Our system will send an email with different subjects and different texts and html. So, we have these 2 services and nodemailer component.

// NodemailerMailProvider.ts
import nodemailer from 'nodemailer'

type SendMailParams = {
  to: string
  subject: string
  text: string
  html: string
}

export class NodemailerMailProvider {
  private transporter: nodemailer.Transporter;

  constructor(){
    this.transporter = nodemailer.createTransport(/* transport options */);
  }

  async sendMail({html,subject,text,to}: SendMailParams){
    let info = await this.transporter.sendMail({
      from: '"Our Application" <contact@ourapp.com>',
      to,
      subject,
      text,
      html,
    });

    console.log("Message sent: %s", info.messageId);
    console.log("Preview URL: %s", nodemailer.getTestMessageUrl(info));
  }
}

//SendWelcomeEmailService.ts
import { NodemailerMailProvider } from "../providers";

export class SendWelcomeEmailService {
  private mailProvider: NodemailerMailProvider

  constructor(mailProvider: NodemailerMailProvider){
    this.mailProvider = mailProvider
  }

  public async execute(email: string, name: string): Promise<void> {
   await this.mailProvider.sendMail({
    to: email,
    subject: "Welcome",
    text: `Welcome to our application, ${name}!`,
    html: `<b>Welcome to our application, ${name}!</b>`,  
   })
  }
}

// SendForgotEmailService.ts
import { NodemailerMailProvider } from "../providers/NodemailerMailProvider";

export class SendForgotEmailService {
  private mailProvider: NodemailerMailProvider

  constructor(mailProvider: NodemailerMailProvider){
    this.mailProvider = mailProvider
  }

  public async execute(email: string): Promise<void> {
   await this.mailProvider.sendMail({
    to: email,
    subject: "Password recovery",
    text: `A password recovery was requested`,
    html: `A <b>password recovery</b> was requested`,  
   })
  }
}

But the system grows and starts to send a lot of emails. So, you decide to use Amazon SES. And now you have SESMailProvider

import nodemailer, { Transporter } from 'nodemailer';
import aws from 'aws-sdk';

type SendMailParams = {
  to: string
  subject: string
  text: string
  html: string
} 

export default class SESMailProvider  {
  private client: Transporter;

  constructor() {
    this.client = nodemailer.createTransport({
      SES: new aws.SES({
        apiVersion: '2010-12-01',
        region: 'us-east-1',
      }),
    });
  }

  public async sendMail({
    to,
    subject,
    html,
    text
  }: SendMailParams): Promise<void> {
    await this.client.sendMail({
      from: '"Our Application" <contact@ourapp.com>',
      to,
      subject,
      text,
      html
    });
  }
}

But now we have a problem, in the constructor of SendForgotEmailService and SendWelcomeEmailService we have this dependency mailProvider: NodemailerMailProvider. Now we have to substitute the type of mailProvider to SESMailProvider.

private mailProvider: NodemailerMailProvider

constructor(mailProvider: NodemailerMailProvider){
  this.mailProvider = mailProvider
}

// now is going to be 
private mailProvider: SESMailProvider

constructor(mailProvider: SESMailProvider){
  this.mailProvider = mailProvider
}

This change affects only 2 services now, but imagine that our application sends email when user log in, when we want o send some notification as a like or a new post. As the system grows, we will have a lot of actions that send an email. So, if we want to change the MailProvider we will need to change in all constructors. That's not good. To solve it, you can create an interface and make the providers implement it.

// IMailProvider.ts
export type SendMailParams = {
  to: string
  subject: string
  text: string
  html: string
} 

export interface IMailProvider {
  sendMail(params: SendMailParams): Promise<void>
}

Now, the providers are going to implement this interface. How both providers has the same method sendMail with the same signature the only change we need to do is to add implements IMailProvider

export class NodemailerMailProvider implements IMailProvider {}
export class SESMailProvider implements IMailProvider {}

And after all the services will not recive NodemailerMailProvider, SESMailProvider or any other implementation. They will recive an IMailProvider.

private mailProvider: IMailProvider

constructor(mailProvider: IMailProvider){
  this.mailProvider = mailProvider
}

Ok, now, we need to create the instance of the services. I'll create just for SendWelcomeEmailService to avoid repetition.

const sendWelcomeEmail = new SendWelcomeEmailService();

This will result in a error because SendWelcomeEmailService recives an IMailProvider. But what is an IMailProvider? NodemailerMailProvider and SESMailProvider are IMailProvider beacuse both of them implements it. I am going to implement SendWelcomeEmailService injecting NodemailerMailProvider

const mailProvider = new NodemailerMailProvider();
const sendWelcomeEmail = new SendWelcomeEmailService(mailProvider);

Now, if you want to change your mail provider the only thing you will need to do is change the mail provider you inject in your services and you won't need to change anything in the service.

But we still have a problem. The IMailProvider is required in more than one service. Then, we need to write const mailProvider = new NodemailerMailProvider() every time we need it. To solve it we can create factory methods. These methods are responsible to create the instances of our dependencies. The first factory we will create is makeIMailProvider that, obviously, will be responsible to create the a implementation of IMailProvider.

export function makeIMailProvider(): IMailProvider {
  return new NodemailerMailProvider()
}

and the factories for the services

// look that the mail provider will be the same for both services and if we have another service needs IMailProvider it would use the same provider too
const mailProvider = makeIMailProvider();

export function makeSendWelcomeEmailService() {
  return new SendWelcomeEmailService(mailProvider)
}

export function makeSendForgotPasswordEmailService() {
  return new SendForgotPasswordEmailService(mailProvider)
}

When you need the services you can just

const sendWelcomeEmail =  makeSendWelcomeEmailService();
// or
const sendForgotPasswordEmail = makeSendForgotPasswordEmailService();

And the best part, if you want to change the implementation of IMailProvider you only need to change the factory method

export function makeIMailProvider(): IMailProvider {
  // return new SendgridMailProvider()
  // return new MailchimpMailProvider()
  return new SESMailProvider()
}

Note that the provider returned in the factory must implement the inerface IMailProvider.

Robert Matin in his book clean arquitecture says

The Dependency Inversion Principle (DIP) tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions.

If you want to see the full code check the repository in https://github.com/murilomaiaa/dependency-inversion

Inversão de dependências exemplificado

Murilo Maia — Wed, 17 Mar 2021 23:48:14 +0000

Quando começamos a programar é normal desenvolvermos programas simples. Quem nunca fez um cadastro de usuários com nome, email, senha e data de nascimento? Porém, conforme nossos os dias vão passando, nosso conhecimento técnico aumenta e nossos desafios também. E, do nada, esse cadastro de usuários agora cadastra também produtos, carrinhos e compras. Agora vamos imaginar que sempre que o usuário crie sua conta ou troque a senha ele receba um email. Você escolhe a maneira mais comum de enviar emails, através de SMTP. Porém, conforme seu sistema cresce você atinge o limite de emails e precisa trocar para um serviço especializado em email como o Amazon SES ou Sendgrid.
E aí? Você vai ter que refatorar todo o seu código para se adaptar a um mudança que deveria ser simples? Se você está começando, provavelmente sim. Porém existe uma maneira, muito fácil, de fazer com que essa mudança altere pouquíssimo código. Como já dizia Linus Torvalds

“Talk is cheap. Show me the code.”

ou em bom português,

“Falar é fácil. Me mostre o código”

Vou usar o Typescript como exemplo para esse artigo mas esse princípio é válido para qualquer linguagem com suporte a orientação a objetos.
Imagine que quando o usuário crie sua conta o sistema envie para ele um email de boas vindas. Esse e-mail vai ser enviado utilizando o Nodemailer. Então teremos:

Vale ressaltar que essas não são as melhores implementações possíveis, pois esse não é o foco do artigo.

//SendWelcomeEmailService.ts
import nodemailer from 'nodemailer'

export default class SendEmailToCreatedUserService {
  public async execute(email: string): Promise<void> {
   let transporter = nodemailer.createTransport({
      // nodemailer config
    });

    await transporter.sendMail({
      from: '"Murilo Maia" <murilomaia.bb@gmail.com>',
      to: email,
      subject: "Bem vindo",
      text: "Bem vindo a nossa aplicação",
      html: "<b>Bem vindo a nossa aplicação</b>",
    });
  }
}

Mas, como citado no começo desse artigo, pode acontecer de você querer trocar o nodemailer para sendgrid. A implementação do service passaria a ser a seguinte.

//SendWelcomeEmailService.ts
import sendgrid from '@sendgrid/mail'

export default class SendEmailToCreatedUserService {
  public async execute(email: string): Promise<void> {
    sendgrid.setApiKey(process.env.SENDGRID_API_KEY)

    sendgrid.send({
      from: {
        name: 'Murilo Maia',
        email: 'murilomaia.bb@gmail.com'
      },
      to: email,
      subject: "Bem vindo",
      text: "Bem vindo a nossa aplicação",
      html: "<b>Bem vindo a nossa aplicação</b>",
    })
  }
}

Até aí não tem tanto problema, agora imagina que você tem 3, 4 ou até 10 ocasiões que você tem envio de email. Você vai ter que refatorar todo o seu código. Pior ainda, imagine que, após pouco tempo você decida usar o Amazon SES? Você vai ter todo retrabalho de mudar essas funções. Você não vai querer isso, certo?
E é exatamente que o dependency inversion, ou inversão de dependência, resolve. O problema maior não é você trocar o serviço de envio de e-mails e sim depender de implementações concretas (biblioteca do Nodemailer, Sendgrid e Amazon SES) ao invés de uma abstração.
Voltando a frase do Linus Torvalds "Talk is cheap, show me the code"
Para começar vamos criar um interface que será a abstração de todos os serviços de email
vale ressaltar que gosto de isolar as regras de negócio em arquivos services e os serviços externos em providers

export default interface IMailProvider {
  // por fins didáticos diminuí o número de parâmetros para o mínimo possível
  sendMail: (to: string, subject: string, html: string) => Promise<void>
}

Agora vamos uma adaptação no service de envio de email

//SendWelcomeEmailService.ts
export default class SendEmailToCreatedUserService {
  private mailProvider: IMailProvider

  constructor(mailProvider: IMailProvider){
    this.mailProvider = mailProvider;
  }

  public async execute(email: string): Promise<void> {
    // validações
    await this.mailProvider.sendMail(
      to: email,
      subject: "Bem vindo",
      html: "<b>Bem vindo a nossa aplicação</b>",
    )
  }
}

Note que agora o nosso service não depende de nenhuma implementação concreta e sim de uma abstração, a interface IMailProvider. Mas e aí? Nós temos a interface mas não temos nenhuma implementação para ela.
Primeiro vamos fazer a implementação do Nodemailer

import nodemailer, { Transporter } from "nodemailer";
import IMailProvider from "../model/IMailProvider";

// implementa nossa interface
export default class NodemailerMailProvider implements IMailProvider {
  private transporter: Transporter;

  constructor() {
    this.transporter = nodemailer.createTransport({
      // nodemailer config
    });
  }
  public async sendMail(to: string, subject: string, html: string) {
    await this.transporter.sendMail({
      from: '"Murilo Maia" <murilomaia.bb@gmail.com>',
      to,
      subject,
      html,
    });
  }
}

E agora a nossa implementação do Sendgrid

import sendgrid from '@sendgrid/mail'

import IMailProvider from "../model/IMailProvider";

export default class SendgridMailProvider implements IMailProvider {
  constructor() {
    sendgrid.setApiKey(process.env.SENDGRID_API_KEY || '');
  }
  public async sendMail(to: string, subject: string, html: string): Promise<void> {
    sendgrid.send({
      from: '"Murilo Maia" <murilomaia.bb@gmail.com>',
      to,
      subject,
      html
    })
  }
}

Agora quando formos instanciar nosso service não podemos fazer da seguinte maneira

const sendWelcomeMail = new SendWelcomeMailService()

Se você fizer isso provavelmente sua IDE vai indicar um erro como "an argument for mail provider was not provided" ou "um argumento para mailProvider não foi informado". Isso acontece pq lá no construtor do service nós estamos esperando um mailProvider do tipo IMailProvider. Então nossa implementação vai ficar assim

const nodemailerMailProvider = new NodemailerMailProvider()
const sendWelcomeMail = new SendWelcomeEmailService(nodemailerMailProvider)

const sendgridMailProvider = new SendgridMailProvider()
const sendWelcomeMail = new SendWelcomeEmailService(sendgridMailProvider)

Agora sempre que você quiser trocar o servico de envio de email é só voce criar uma classe que implementa a interface IMailProvider e na hora de instanciar os services que dependam dessa interface você passar o novo serviço.

Bônus

O que já estava bom, ainda dá pra melhorar. Imagine que você instancie esse service em mais de um lugar. Se toda vez que você for trocar o serviço de envio de email você tiver que instanciar tudo de novo vai dar um pouco de trabalho. Não é nada muito cansativo mas pode ser evitado utilizando fábricas.

// MakeSendWelcomeMailService.ts
export default function makeSendWelcomeMailService(): SendWelcomeMailService {
  const nodemailerMailProvider = new NodemailerMailProvider()
  const sendWelcomeMail = new SendWelcomeEmailService(nodemailerMailProvider)
  return sendWelcomeMail
}

Agora, sempre que você for instanciar o service você vai fazer

const sendWelcomeMail = makeSendWelcomeService()

Assim, se você instancia seu service em mais de um lugar, basta trocar no makeSendWelcomMailService. Além disso, você desacopla ainda mais o seu código.