Eu tenho lido mais do que escrito nesses últimos dias, mas hoje vamos tentar diminuir a distância entre esses dois processos, já que esse último encontra-se consideravelmente atrasado em relação ao primeiro 😂.

Na parte 3 do livro, Uncle Bob discute os blocos que constroem qualquer sistema: código. Para além de uma sintaxe particular, toda linguagem de programação adota um ou mais paradigmas. E é sobre esse fundamento e sua importância para a arquitetura de que trata essa seção.

A essa altura, fiquei um pouco descrente: imaginei que viria por aí mais do mesmo sobre a velha discussão do assunto. Mas eu me surpreendi bastante. Os quatro capítulos que vieram em seguida trouxeram uma abordagem única que eu nunca tinha visto antes. E com zero enrolação: num livro sobre arquitetura de software, o autor sabe que você, leitor, está familiarizado com esses paradigmas. O que ele traz de forma bastante direta é uma análise sobre:

• a motivação por trás de cada um, isto é,
• qual problema cada paradigma tentava resolver dentro do contexto histórico em que foi criado e;
• qual a relevância disso para arquitetura.

Esse entendimento realmente faz diferença quando nos perguntamos qual melhor maneira de resolver determinado problema.

Além disso, Uncle Bob desmistifica alguns pontos dentro deste tópico e faz algumas observações notáveis que podem ser bastante surpreendentes.

Por exemplo, geralmente quando se pensa em OOP (Object Oriented Programming), a primeira coisa que vem à mente são classes. Por conseguinte, frequentemente essas duas ideias são associadas no pensamento de que só é possível escrever código OO com esse recurso. Quando falo de “classe” me refiro aos artefatos usados nas linguagens de programação para implementar esse conceito (pense em uma declaração de classe em Java ou em TypeScript). Entretanto, não é bem assim.

No JavaScript, por exemplo, é perfeitamente possível implementar as ideias e conceitos do paradigma sem jamais escrever uma classe (usando funções e closures). Falo do JavaScript porque é a linguagem que eu mais domino hoje (junto com o TypeScript), mas isso provavelmente vale para as demais: Uncle Bob chega ao extremo de mostrar como alcançar implementações das ideias do OO em C! Sim, C!

Claro, as linguagens modernas trazem formas infinitamente mais convenientes de fazer isso. O ponto aqui é o de que, ao invés de se prender aos artefatos específicos utilizados nas linguagens que adotam o paradigma X ou Y, devemos, ao contrário, entender qual o problema que cada paradigma tenta resolver e quais são as ideias e conceitos das quais cada um se vale para tanto.

Dessa forma, podemos decidir com mais confiança sobre o uso de um ou de outro quando nos deparamos com os problemas. Isso porque a maioria das linguagens de programação modernas são multiparadigma e temos a opção de escolher qual melhor abordagem em cada situação. Ou podemos escolher uma linguagem específica que adota um paradigma de forma mais inflexível (Haskell é uma que vem à mente) se soubermos que aquele é o paradigma ideal para o escopo do problema que estamos tentando resolver.

De todo modo, ao final dessa parte do livro, você vai sair com um aprofundamento nesse tema que você talvez nem achasse que precisava (meu caso).

…

A abordagem do Uncle Bob é começar dos fundamentos e ir construindo o conhecimento até chegar nas discussões amplas e estratégicas. Depois de falar sobre paradigmas de programação, a sessão seguinte fala sobre princípios usados para construir e interconectar os componentes de um sistemas. Esses princípios são aqueles referidos pelo famoso acrônimo SOLID.

Essa discussão, entretanto, nos interessa de perto e pretendo fazê-la de forma minuciosa nos próximos artigos.

Vejo vocês lá!

Este artigo é parte da série Clean Architecture baseada no livro de mesmo nome do Uncle Bob. Confira os demais:

Seguinte: Princípios SOLID: o princípio da Responsabilidade Única

Anterior: Arquitetura: o bem maior