Princípios SOLID com Typescript
Uma explicação rápida e prática de SOLID utilizando Typescript
SOLID é um acrônimo para cinco princípios de padrões de projeto em OOP criado por Robert C. Martin, que tem o intuito de facilitar o desenvolvimento e manutenção de software.
Os cinco princípios são:
- S ingle Responsibility Principle — Princípio de responsabilidade única.
- O pen/Closed Principle — Princípio de Aberto/Fechado.
- L iskov Substitution Principle — Princípio da Substituição de Liskov.
- I nterface Segregation Principle — Princípio da Segregação de Interface.
- D ependency Inversion Principle — Princípio da Inversão de Dependência.
Princípio de responsabilidade única
“Uma classe deve ter um, e somente um motivo para existir.”
Este princípio indica que toda classe, todo método, função ou componente de seu código deve ter uma única e exclusiva responsabilidade. Uma classe que toma pra si muitas responsabilidades dentro da aplicação, trás baixa coesão ao seu código resultando em baixo nível de manutenabilidade.
Procure sempre segregar as responsabilidades de suas aplicações em outras classes a modo que fique fácil de entender o papel dessa classe em sua aplicação numa simples leitura do código.
Se possível, sempre construa métodos que realizem apenas uma única função. Não codifique ações inesperadas dentro de seus métodos, isso não é intuitivo, seja objetivo no desenvolvimento de seus métodos.
Violando o Princípio
Segue um exemplo de código que viola o Princípio de Responsabilidade Única em Typescript:
Cumprindo o Princípio
Para este exemplo a maneira correta é dividir as responsabilidades de obter o nome da tarefa e a de salvar um registro no Banco em duas classes distintas, classe Atividade e RepositorioAtividade respectivamente.
Como mostra o exemplo abaixo:
Princípio de Aberto/Fechado
“Você deve ser capaz de estender o comportamento de uma classe sem modifica-la.”
Como citado acima, este princípio defende a ideia que a classe deve ter a Abertura para extensão, mas Fechamento para modificação. Isso é possível desenvolver utilizando princípios de Orientação a Objeto como herança e composição.
Cumprindo o Princípio
Abaixo temos um exemplo de classe de CartaoCredito que possui métodos de obterCartao(), obterExpiracao() e descontoMensal(). No nosso cenário temos outras duas categorias de cartão de crédito que disponibilizam um desconto mensal diferenciado, que são as categorias Silver e Gold.
Segue exemplo:
Violando o Princípio
Abaixo temos o mesmo cenário anterior, porém mudando totalmente o comportamento e composição da classe CartaoCredito:
Segue exemplo:
Princípio da Substituição de Liskov
“Classes derivadas devem ser facilmente substituídas pelas classes base.”
Este conceito foi introduzido por Barbara Liskov em 1987, no qual defende a ideia que uma classe base pode ser substituída em qualquer momento por suas classes herdadas sem ser modificada.
Cumprindo o Principio
Abaixo temos um exemplo de classe Pessoa que tem as propriedades de Nome e Sobrenome, com uma ação de DizerSaudacao. Para cada nacionalidade foi criada uma classe que herda de Pessoa, e diz sua saudação conforme sua língua.
NOTA: Vale citar que é possível cumprir esse princípio não só utilizando classes abstratas como mencionado acima. Também é possível cumprir utilizando interfaces ou até classes base simples.
Princípio da Segregação de Interface
“Crie pequenas interfaces granulares que são específicas do cliente.”
Esse princípio defende que devemos segregar ao máximo as nossas interfaces, tomando como partida de segregação a responsabilidade que essa nova interface irá assumir. Devemos evitar interfaces muito genéricas, elas devem cumprir a sua única responsabilidade proposta.
É um princípio simples de aplicar, mas agrega em boa parte a coesão no seu código.
Violando o princípio
Abaixo temos um exemplo de interface chamado Impressora que possui as funções de copiar, imprimir e grampear. Porém ao implementar uma impressora simples, que não copia e nem grampeia, a classe se torna incoerente. Segue exemplo:
Cumprindo o Princípio
Segregando as interfaces por cada responsabilidade fica mais fácil de desenvolver um código coeso. Veja o exemplo abaixo:
Princípio da Inversão de Dependência
“Sempre dependa de abstrações, nunca de implementações concretas.”
O Princípio de Inversão de Dependência indica que módulos de alto nível não devem depender de módulos de baixo nível, mas ao invés disso, depender de abstrações.
Em poucos miúdos, procure sempre depender de interfaces e não de classes concretas.
Violando o princípio
Abaixo temos dois exemplos no qual as dependências são concretas.
Primeiro exemplo:
Segundo exemplo:
Cumprindo o princípio
A seguir temos a mesma implementação citada acima, porém as dependências são abstrações e não implementações:
Nota: Vale lembrar que quando temos uma dependência de abstração é recomendável providenciar a implementação de dependências nas abstrações durante o tempo de execução da aplicação.
Em qualquer linguagem existem frameworks que fazem esse trabalho.
Já que estamos falando de Typescript, recomendo a utilização do Inversify que tem sido muito popular na comunidade.
Conclusão
O SOLID não resolverá todos os seus problemas dentro de sua aplicação, mas como vimos acima, ele é uma abordagem bem objetiva de como utilizar boas práticas de Orientação a Objetos com simples abordagens.
Tente praticar, ou observar no seu dia a dia, aonde estão sendo cumpridos ou violados cada um desses principios, e tente entender o impacto que cada implementação trará no seu dia a dia.
Claro que em tudo em tecnologia não existem verdades absolutas que se moldam em qualquer lugar. Existem cenários e contextos diferentes pra tudo. O SOLID foi extraído de uma visão do Uncle Bob a partir do contexto que ele vivia na época. É indiscutível a agregação de valor que esse conteúdo trouxe para a comunidade em linhas gerais, porém procure entender se faz sentido no seu dia a dia e se suas ideias compactuam com a proposta do SOLID.
Abraços!
