Princípios do SOLID com TypeScript
Veja nesse artigo um exemplo prático do principio OCP — Princípio Aberto-Fechado
Introdução
Dando continuidade a minha série de artigos sobre os princípios do SOLID com TypeScript e aproveitando a liberação do episódio 2 do nosso podcast: DevShow #22 SOLID OCP. Hoje irei abordar o segundo principio do SOLID, OCP.
OCP — Princípio Aberto-Fechado
O OCP diz que as entidades de software (classes, módulos, funções… ) devem ser abertas para ampliação, mas fechadas para modificação.
De forma mais detalhada, diz que podemos estender o comportamento de uma classe por meio de herança, interface e composição, mas não podemos permitir a abertura dessa classe para fazer modificações.
Em uma pesquisa rápida pela internet eu achei uma imagem que descreve bem esse principio:
Violação: Note que na imagem com fundo rosa nós temos um robo que começa com uma faca falando que pode cortar e depois de uma nova demanda esse mesmo robo troca a faca por um rolo de pintar.
Essa imagem lembra algo? rs
É muito comum no desenvolvimento de software situações como essa onde temos uma classe que tem uma determinada funcionalidade e ao decorrer da evolução do sistema ela tenha que sofrer algumas mudanças. É nesse momento que devemos lembrar desse principio (OCP).
Na segunda imagem nós temos um robo que começa com uma faca falando que pode cortar e depois de uma nova demanda aparece com um rolo de pintar na outra mão.
Em uma breve analise, note que ele não alterou (perdeu) como na primeira imagem a funcionalidade de cortar, com a evolução ele acabou ganhando uma nova funcionalidade, a de pintar.
Esse seria o comportamento perfeito para que consigamos atender a nova demanda e ainda garantir que o que esta no publicado não seja alterado.
Bom, mas como ficaria isso no código?
Para que esse principio fique mais claro, vamos criar um exemplo prático utilizando o TypeScript.
Exemplo prático
Vamos começar com um código simples:
Nessa classe nós temos uma classe com um método chamado Export, que valida o tipo de documento e dependendo do tipo que ele for, ele exporta os dados que estiverem em data para um dos formatos: pdf ou excel.
Até aqui tranquilo, nós temos um código simples que esta validando o tipo de arquivo que esta em um enum.
Agora imagine o seguinte cenário, chegou uma nova demanda para exportar os dados para Word, como você faria essa alteração?
Pensando rapidamente nós colocaríamos o novo tipo no enum e adicionaríamos um if no método exportar correto?
Algo assim:
Demanda done, mas dai vem aquela pergunta, essa é a melhor forma de resolver a nossa demanda?
A resposta é não, resolvemos a demanda, mas em uma breve analise estamos dando mais uma responsabilidade para nossa classe Arquivos, além de estar violando o primeiro principio do SOLID o SRP, o correto pensando no OCP seria estender essa classe, não atribuir mais uma funcionalidade nela, com a possibilidade de quebrar algo existente.
Agora pensando no OCP, como resolver essa demanda ?
Na realidade é bem simples, veja a seguir como ficaria a nossa classe:
Com essa implementação nós estamos atendendo a nova demanda, garantindo o SRP (Removendo a responsabilidade de validar o tipo da classe) e o OCP, garantindo que a classe Arquivos esteja fechada para mudança, mas aberta para extensão.
Bem simples e mais organizado né?
Bom, com isso nós finalizamos mais esse artigo, espero que tenham gostado e até um próximo artigo pessoal.
