SOLID e sua aplicabilidade no paradigma funcional

SOLID é originalmente um conjunto de princípios de design patterns voltados a POO (Programação Orientada a Objetos) identificados por Robert C. Martin, também conhecido como Uncle Bob, que caso seguidas trazem diversos benefícios técnicos e evitam alguns problemas relacionados à estrutura do código.

De acordo com o próprio Uncle Bob, os benefícios do SOLID são universais, tangíveis a todo modelo de programação e código, e que os princípios são adaptáveis às necessidades de quem tem um problema que envolve desenvolvimento de software[1].

Sabendo disso, a adaptação destes conceitos para o paradigma funcional é algo necessário. Vamos começar especificando letra por letra deste conceito, sua aplicabilidade e ganhos.

S, o Single Responsibility Principle (Princípio de responsabilidade única)

Este princípio define que funções devem ter uma única responsabilidade e, que um determinado conjunto delas execute alguma regra, como se cada função fosse uma etapa de um algoritmo. É o princípio mais fácil de se universalizar, pois você delega uma tarefa única a uma function, visando a simplicidade do código e facilitando testes, além de ter adaptabilidade ao código onde a lógica daquela function precisar ser aplicada.

Na linguagem funcional, aplicar esta lógica é simples, principalmente na relação classe-function e module-function que, até mesmo visualmente, é fácil de perceber. Aplicar uma lógica unitária em uma function em um módulo em nada difere de POO e tem os mesmos ganhos. A adaptabilidade é total.

O, o Open-closed Principle (Princípio Aberto-Fechado)

Este princípio postula que você pode mudar o comportamento do seu sistema sem mudar o código. Basicamente, este princípio nos permite escalar sistemas sem a necessidade de alterá-los, apenas adicionando novas funcionalidades.

Apesar de ser claro que o princípio é baseado no conceito de herança de POO, onde uma subclasse herda uma lógica de uma superclasse, no paradigma funcional existe o conceito de funções de ordem superior, as quais recebem funções como argumento e retornam uma função como resposta. Desta forma, podemos fazer com que o comportamento de um sistema permaneça o mesmo, mas podemos acrescentar novas funções de entrada, desde que corretamente arquitetadas.

L, o Liskov Substitution Principle (Princípio de Substituição de Liskov)

Este princípio define que os objetos de uma superclasse devem poder ser substituídos por objetos das subclasses sem quebrar a aplicação. O que requer que o comportamento dos objetos das subclasses sejam homólogos aos da superclasse.

Esta visão é como um acordo entre partes, que decide os padrões de composição do código, similar com o conceito de design por contrato de Bertrand Meyer. Um acordo é ótimo para o bom funcionamento de um código e o beneficia através de padrões estabelecidos entre funções de entrada e suas saídas em funções de ordem superior no paradigma funcional.

I, o Interface Segregation Principle ou ISP (Princípio da segregação de Interface)

Este princípio diz que o uso de interfaces deve ser feito de forma específica, e que ter várias interfaces bem específicas é melhor do que ter uma grande que redireciona para todos. O princípio se baseia em “nenhum cliente deve ser forçado a depender de métodos que não utiliza”.

Isto faz com que a manutenção do sistema seja muito mais desacoplada e assim, torna-se fácil implementar novos códigos, desde que neste padrão. No paradigma funcional, criando o mínimo de campos obrigatórios para que o sistema opere em uma struct única que irá ser passada em uma função de entrada, consegue-se alcançar resultados análogos ao que acontece em POO.

D, o Dependency Inversion Principle (Princípio da segregação de Interface)

Este princípio diz que o seu sistema precisa ter alta coesão e baixo acoplamento. Basicamente é você fazer com que módulos e funções relacionadas se comuniquem com funções não relacionadas o mínimo possível, o que independente do paradigma é uma boa prática.

Todos os princípios acima contribuem para uma excelente qualidade para o código e só tem a agregar a qualquer que seja o paradigma de programação. Melhorias gerais em padrões de código e arquitetura são importantes não somente para a comunidade como um todo, mas também para o seu time. Padrões ajudam muito em definições, não só intra como inter times, fazendo com que a comunicação flua melhor e os projetos sigam com o alinhamento de todos os envolvidos. Entender mais sobre isso me fez ver mais valor nos cuidados para a aplicação destes padrões, afinal, acho que independente do paradigma, só temos a ganhar.