Se você pesquisar pela internet, tenho certeza que vai encontrar vários artigos sobre SOLID. Alguns muito bons, outros sofrem com o efeito “telefone sem fio”. Para não ser mais um, fui pesquisar. Encontrei o livro “Arquitetura Limpa” (Clean Architecture) de Robert C. Martin que vem compilar alguns conceitos e atualizar alguns outros. E assim nasce essa série de artigos.
SOLID me acendeu a luz amarela
Todo mundo tem uma pessoinha interna, segurando um semáforo de percepções. Verde é o equivalente a “está tudo bem”, amarelo é “Eita, como assim? Tem caroço nesse angu” e o vermelho é “Run you fools”. E eu começo admitindo que na maior parte dos contatos que tive com SOLID, esta pessoinha acendia a luz amarela. Alguma coisa as vezes não batia. Parece que faltava um pouco de contexto. Mas eu não dava a devida atenção. Afinal, “Foi o Tio Bob quem disse” e o que ele diz não se coloca em dúvida. Realmente.
Recentemente chegou em minhas mãos o mais novo produto da Série Robert C. Martin: “Arquitetura Limpa”. E qual não foi a minha surpresa ao me deparar com cinco capítulos dedicados ao tema SOLID. Meu primeiro impulso foi pular esses capítulos. “Eu já li tudo o que havia para ser dito sobre SOLID”, pensei. A luzinha vermelha acendeu. Eu precisava ler, só pra matar a dúvida. Continuei com a leitura linear. A primeira frase me impactou:
“De todos os princípios SOLID, o Princípio da Responsabilidade Única (SRP)
MARTIN, Robert C. Arquitetura Limpa: o guia definitivo para estrutura e design de software. Alta books, 2018
provavelmente é o menos compreendido.”
Neste exato instante aquela pessoinha do semáforo me olhou com cara feia, tomando um copo cheio de “eu te avisei”. Imediatamente parei a leitura e comecei a refletir sobre cada um dos princípios SOLID e a questionar a mim mesmo sobre o que eu havia lido, ouvido e apreendido. Voltando à leitura, realmente, minhas suspeitas estavam corretas. Então, fica aqui a lição: Quando a pessoinha acender a luz amarela, dê ouvidos a ela!
E é por isso que resolvi fazer esta série de artigos “SOLID de verdade”. Não espere que eu siga o acrônimo na sua ordem. No mesmo livro, Bob Martin diz que foi sugestão de um amigo reorganizar os padrões para que formassem a palavra SOLID. O que me diz que havia, antes, uma ordem. E como todo bom programador, havia uma ordem lógica. Assim, pretendo seguir uma ordem lógica que pode ajudar você a absorver melhor os conceitos dentro de seus respectivos contextos. E por falar em contexto…
O contexto para SOLID
Como é a base de código do seu software? Olhando para o velho guerreiro que sustenta a “firma” por tantos anos, a tua base de código pode se parecer com aquilo que Brian Marick chamou de Big Ball of Mud; um código tão bagunçado que não é possível sequer perceber a arquitetura nele. Regras de negócio e detalhes técnicos em uma mistura tão homogênea que é impossível separá-los.
E me permita ser bastante polêmico sincero: As boas
práticas de desenvolvimento não servem para manter esse software. Tentar
aplicar SOLID, padrões de projeto ou o que quer que seja só irá aumentar a
complexidade e a bagunça. Continuará a ser uma bola de lama, mas com petúnias.
Se houver a possibilidade de construir um módulo novo, ou reescrever um
determinado contexto do software, aí sim temos uma boa oportunidade de mostrar
o poder de uma boa arquitetura e base de código bem escrita.
Tudo o que é escrito por Martin Fowler, Robert Martin, Eric Evans, Sam Newman entre outros são boas práticas para desenvolver software seguindo alguns padrões arquiteturais bastante parecidos e que se sucedem em termos de granularidade e complexidade. Do monolito modularizado, você pode pular para DDD ou Ports and Adapters por exemplo. Desses, você está a um passo de escrever micro serviços, depois nano serviços, FaaS… Se você não tem intenção de escrever software utilizando alguma dessas arquitetura (e seus correlatos), SOLID não fará sentido pra você. Talvez apenas em um novo projeto.
O que está por vir?
Teremos cinco artigos, cada um abordando um princípio diferente. Ao invés de apenas demonstrar o que cada princípio pretende, desejo demonstrar que problema ele veio resolver, como ele resolve e demonstrar com exemplos de código. Assim, acredito, teremos um bom equilíbrio entre teoria e prática. Eu aconselho fortemente a não pular a parte teórica. Ela vai ser importantíssima para que você possa reaproveitar os conceitos nos seus projetos.
Como eu disse, não pretendo seguir a ordem do acrônimo. Qual você acha que deveria ser a ordem mais lógica a ser adotada?
Até o próximo artigo!
Lista de artigos da série: