SOLID: Um assunto necessário

Essa semana tive a oportunidade de apresentar um Meetup sobre SOLID e foram diversas as dúvidas sobre um material complementar. E então eu pensei: Por quê não fazer deste o meu primeiro assunto técnico aqui no medium?

Então decidi abordar em uma série de 5 posts cada um destes princípios que está totalmente em alta nos últimos tempos.

É claro que princípios como SOLID existem a muitos anos, mas a realidade é que ainda hoje, muitas empresas ignoram estes princípios por considerar overengineering.

Mas acredite quando eu falo que não é. O custo de refatorar um projeto mal estruturado é bem maior do que o tempo gasto criando ele já pensando nestes padrões.

O engraçado é que toda vez que parei pra ler um artigo sobre SOLID, me deparei com definições altamente abstratas. Eu lia a definição e olhava para o meu código, e não conseguia enxergar COMO aplicar SOLID no meu código.

Mas afinal o que é SOLID?

O S.O.L.I.D é um acrônimo que representa cinco princípios da programação orientada a objetos e design de código teorizados pelo nosso querido Uncle Bob (Robert C. Martin) por volta do ano 2000.

Tá. Esse tipo de definição vemos em todos os artigos da internet. Mas traduzindo em poucas palavras: São boas práticas que, se não seguir, as chances do seu projeto se tornar algo extremamente complexo e de difícil manutenibilidade são grandes. Então, que tal começar a colocar os princípios em prática desde já?

Não devemos tentar atingir o SOLID. Devemos usar destes princípios para atingir o que queremos: seja um nível máximo de abstração, reutilização de código, escalabilidade, etc.

Então vamos juntos, ver como aplicar de forma prática, cada um destes princípios?

[S]ingle Responsibility Principle

O primeiro princípio, como o próprio nome diz, trata-se de um princípio de responsabilidade única, ou seja: devemos sempre lembrar que um método e/ou classe deve possuir um único motivo para ser modificado.

Tá, mas até agora falei exatamente o que lemos em diversos artigos pela internet e continua abstrato demais e essa não é minha ideia. Então que tal usarmos exemplos mais práticos?

Fiz uma classe em Kotlin chamada User, bem básica aqui, somente com 3 funções: getName(), setName(), porém, temos uma função que conterá a validação do usuário.

Sei que para algumas pessoas, pode não haver problema algum nesse tipo de estrutura, porém, se formos considerar o princípio em que diz que: Uma classe deve ter um único motivo para ser alterado, vemos que isso não está sendo seguido nessa classe. Por quê? Pois essa classe pode, basicamente, mudar por dois motivos: Regras de usuário, e regras de login do usuário.

A questão é que, por mais que pareça que está tudo dentro do mesmo contexto, não é de responsabilidade da classe User saber as regras para que seja feita o login do mesmo.

Da forma que está o código hoje, não respeitando o princípio de responsabilidade única, temos diversas desvantagens como:

• dificuldade de reutilização de código (afinal, vai que em algum outro ponto do código precisarmos logar o usuário novamente. Teríamos que chamar a classe usuário para utilizarmos somente um método específico);
• Há também o fato de que colocando tudo dentro de uma única classe, o custo de manutenção depois é absurdo, pois os desenvolvedores gastarão mais tempo tentando entender a lógica de tudo que está contido naquela classe, do que fazendo a manutenção em si.

A sua classe ou método não deve ser canivete suíço, ou seja, fazer mil e uma tarefas. Devem ser específicas, diretas e sucintas.

Então se formos considerar o código visto anteriormente, vemos que faz total sentido criar uma classe específica para a validação do usuário, que chamei de Validation. Nessa nova classe, podemos colocar regras de validações, extraindo toda essa lógica da classe de Usuário que não deveria conhecer esse tipo de lógica.

E assim, a minha classe User ficará responsável unicamente pelos dados do usuário, sem conhecer as regras de validação do mesmo:

No início você pode ter um pouco de dificuldades em saber quando faz sentido ou não separar as responsabilidades de uma classe e/ou método, mas tenha sempre em mente: Eu posso, no futuro, precisar mexer nessa classe por mais de um motivo (de diferentes contextos)? Se a resposta for sim, significa que seu código pode (e deve) ser separado.

Lembrando que esse post é o primeiro de uma série de 5, onde abordarei de forma menos abstrata os princípios de SOLID.

Me siga no LinkedIn para ficar por dentro dos próximos!

Code Like a Girl 👧