Princípios SOLID com Angular

SOLID é um conceito muito interessante em qualidade de código e é fácil aprender seus conceitos com exemplos de desenvolvimento back-end. Mas quem é dev front-end também tem muito a ganhar ao conhecer o SOLID. 

No artigo de hoje eu trago um resumo sobre o que é SOLID com Angular. Estes princípios foram definidos nos anos 2000 por Robert C. Martin e Michael Feathers, no intuito de promover técnicas e conceitos que facilitassem o desenvolvimento e manutenção de sistemas complexos de computação.

Robert C. Martin, mais conhecido como Uncle Bob é uma das referências em engenharia e arquitetura de software no mundo, sendo um dos assinantes do Manifesto Ágil, além de criador de conceitos consagrados na comunidade como Clean Code e Clean Architecture. 

Não distante, Michael Feathers, também é reconhecido como um dos grandes nomes do mundo do desenvolvimento de software, foi, de fato, o criador do acrônimo S.O.L.I.D.

Se você já ouviu falar de Clean Code e Clean Architecture saiba que estes princípios formam a pedra angular de todos estes conceitos.

Assim, se o seu objetivo é tornar-se um bom engenheiro de software, é de suma importância o entendimento destes princípios antes de aprofundar em qualquer modelo arquitetural mais rebuscado.

Os cinco princípios do solid

[S]ingle Responsibility Principle: Princípio da responsabilidade única.

[O]pen/Closed Principle: Princípio de aberto e fechado.

[L]iskov Substituition Principle: Princípio de substituição de Liskov.

[I]nterface Segregation Principle: Princípio da segregação de interface.

[D]ependence Inversion Principle: Princípio de inversão de dependência.

Quer saber mais sobre o Angular? Acompanhe o Blog e o meu curso => Aqui

[S] – Single Responsibility Principle: Princípio da responsabilidade única

Este princípio nos diz que “uma classe deve ter um, e somente um, motivo para mudar”, porém pode ser aplicado a funções, componentes, entidades, etc. 

Esse princípio declara que uma classe deve ser especializada em um único assunto e possuir apenas uma responsabilidade dentro do software, ou seja, a classe deve ter uma única tarefa ou ação para executar. 

Formas de utilizar o conceito: errado

export class LanchesComponent implements OnInit {
  private dbLanches: Array<{ id: number; lanche: string; preco: string }> = [];
 
  constructor() {}
 
  ngOnInit(): void {}
 
  public create(lanche: string, preco: string) {
    return this.dbLanches.push({
      id: this.dbLanches.length,
      lanche,
      preco,
    });
  }
 
  public find(id: number) {
    return this.dbLanches.find((res) => {
      return res.id === id;
    });
  }
 
  public update(id: number, lanche: string, preco: string) {
    const find = this.find(id);
 
    if (!find) return null;
 
    find.lanche = lanche ? lanche : find.lanche;
    find.preco = preco ? preco : find.preco;
 
    return find;
  }
 
  public delete(id: number) {
    this.dbLanches.filter((idArray) => {
      return idArray.id !== id;
    });
  }
}

Neste caso temos alguns problemas, pois ficou tudo dentro de um componente e o S é chamado de Single Responsibility Principle. 

Devido a isso, se um outro componente quiser utilizar essas funções, teríamos que criar tudo novamente? E a resposta é não, o correto é separarmos em um serviço e assim usamos em uma forma desacoplada e reutilizada para outros componentes etc.

Formas de utilizar o conceito: correto

export class LanchesComponent implements OnInit {
  constructor(
    private dbLanchesService: DbLanchesService
  ) {}
 
  ngOnInit(): void {}
 
  public create(lanche: string, preco: string) {
    return this.dbLanchesService.create(preco, lanche)
  }
 
  public find(id: number) {
    return this.dbLanchesService.find(id);
  }
 
  public update(id: number, lanche: string, preco: string) {
    return this.dbLanchesService.update(id, lanche, preco)
  }
 
  public delete(id: number) {
    return this.dbLanchesService.delete(id)
  }
}

[O] – Open/Closed Principle: Princípio de aberto e fechado

Segundo Uncle Bob, “as entidades de software (classes, módulos, funções, etc.) devem ser abertas para ampliação, mas fechadas para modificação”. 

Passando para a definição desta regra: classe/objeto deve ser aberto para expansão, mas fechado para modificação. 

O que isto significa?

Você precisa escrever o código de tal forma que novas funcionalidades possam ser introduzidas sem modificar o código existente.

Inicialmente, referia-se à realização do polimorfismo (alteração do comportamento dos objetos) por meio de herança, ou seja, criar uma classe base e herdar dela.

“Você deve ser capaz de estender o comportamento de uma classe sem modificá-la.”

Formas de utilizar o conceito: errado

export class Cartoes {
  private juros: number = 0.2;
 
  constructor() {}
 
  protected get getJurosMensal() {
    return this.juros;
  }
 
  public jurosMensalCartaoSilver() {
    return (this.getJurosMensal + 0.03).toFixed(2);
  }
 
  public jurosMensalCartaoGold() {
    return (this.getJurosMensal + 0.05).toFixed(2);
  }
}

Formas de utilizar o conceito: correto

export class Cartoes {
  private juros: number = 0.2;
 
  constructor() {}
 
  protected get getJurosMensal() {
    return this.juros;
  }
}

export class CartaoSilver extends Cartoes {
  constructor() {
    super();
  }
 
  public jurosMensalCartaoSilver() {
    return (this.getJurosMensal + 0.03).toFixed(2);
  }
}

export class CartaoGold extends Cartoes {
  constructor() {
    super();
  }
 
  public jurosMensalCartaoGold() {
    return (this.getJurosMensal + 0.05).toFixed(2);
  }
}

Veja que fizemos o extends da classe e usamos dentro do nosso contexto atual.

Cartão gold e silver ficaram dentro de suas classes utilizando o getJurosMensal da classe extendida.

Então abrimos para ampliação devido o extends e fechamos para modificação. A modificação veio dentro da sua própria responsabilidade.

[L] – Liskov Substituition Principle: Princípio de substituição de Liskov

O princípio de substituição de Liskov está ligado diretamente ao princípio anterior, o OCP (Open Closed Principle). Criado por Barbara Liskov em 1987, durante a conferência “Data Abstraction”

No qual defende a ideia que uma classe base pode ser substituída em qualquer momento por suas classes herdadas sem ser modificada.

export abstract class Lanche {
  public nome: string;
 
  constructor(nome: string) {
    this.nome = nome;
  }
 
  /*
   * @returns Retorna qual carne é usada no lanche
   */
  abstract carneDoLanche(): string;
}

Vimos que aqui ele gera um modelo de como devemos implementar a em nossa nova classe.

Repare que temos carneDoLanche(), nome e no super o valor “picanha” que irá compor o valor do nome.

export class LanchePicanha extends Lanche {
  constructor() {
    super('Picanha');
  }
 
  public carneDoLanche(): string {
    return this.nome;
  }
}

[I] – Interface Segregation Principle: Princípio da segregação de interface

Neste caso utilizaremos interfaces, porém é bem parecido com o exemplo anterior.

Ele mesmo já diz implements ( implementar ), ele mostra que precisamos para implementar esta classe.

export interface ILanches{
  nome: string,
  carneDoLanche(): string
}

export class LanchePicanha implements ILanches {
  public nome: string = 'Picanha';
  constructor() {
  }
 
  public carneDoLanche(): string {
    return this.nome;
  }
}

Veja que usamos o implements ao invés do extends e não precisamos utilizar o super(“Picanha”).

A própria classe entende as necessidades que devemos utilizar nela. Legal né?

Implements é usado quando uma classe implementa uma interface, extends é quando uma classe estende uma outra classe (concreta ou abstrata) ou quando uma interface estende uma outra interface.

Ou seja, a keyword extends é usada para quando um tipo (classe ou interface) é derivado do seu mesmo tipo, e o implements é sempre que deseja fazer uma implementação, no caso uma classe implementa uma interface.

[D] – Dependence Inversion Principle: Princípio de inversão de dependência

Este princípio diz que toda classe deve depender de abstrações e não de implementações. Segundo Uncle Bob.

• Módulos de alto nível não devem depender de módulos de baixo nível.
• Ambos devem depender da abstração.
• As abstrações não devem depender de detalhes.
• Detalhes devem depender de abstrações.

Sendo bem direto, procure sempre depender de interfaces e não de classes concretas.

Formas de utilizar o conceito: errado

export class Lanche {
  public nome!: string;
  public preco!: number;
}

export class LanchePicanha {
  constructor() {}
 
  public comprarLanche(): Lanche <- classe{
    return {
      nome: "Picanha",
      preco: 12
    }
  }
}

Veja que tipamos o comprarLanche() com a classe Lanche e isso é errado para o Dependence Inversion Principle. O correto é tiparmos com uma Interface.

Formas de utilizar o conceito: correto

export interface ILanches{
  nome: string,
  preco: number
}

export class LanchePicanha {
  constructor() {}
 
  public comprarLanche(): ILanches <- Interface{
    return {
      nome: "Picanha",
      preco: 12
    }
  }
}

Conclusão

O SOLID, como representam um desenvolvimento orientado a objetos em sua essência, se tornam uma porta de entrada para se alcançar essa escrita de código saudável e coerente. 

É um padrão de projeto que pode se mostrar assustador no início, e nem sempre conseguimos aplicar com maestria, mas a prática e constância, aos poucos trará a experiência levamos ao amadurecimento do nosso código.