Jornada Frontend

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

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

[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

Formas de utilizar o conceito: correto

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.

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.

[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.

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

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

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. 

Tenha uma carreira
Front-end de Sucesso!

Ebook - JORNADA FRONT-END

Fruto de mais de 7 anos estudando e trabalhando com Front-end, a "Jornada Front-end - O Guia Definitivo" é um manual completo para todos que querem subir em suas carreiras do zero ou subir do seu nível atual.

Ebook enviado com sucesso! Verifique sua caixa de e-mail.

Share This