Como SOLID pode ajudar a programar?

Os princípios SOLID contribuem para a evolução e a manutenção de software ao permitir a inclusão de novos requisitos de forma fácil

SOLID é um dos conjuntos mais populares de princípios de desenvolvimento de software orientado a objetos (OOD) e design de código. O conceito estabelece uma série de práticas que ajudam a escrever um código flexível, escalável, sustentável e reutilizável, facilitando a evolução e a manutenção dos programas.

À medida que os softwares crescem, os princípios SOLID reduzem a complexidade dos aplicativos ao permitirem alterar uma área do software sem modificar outras. Com isso, os projetos ficam mais fáceis de entender, manter e estender, e desenvolvedores podem criar softwares adaptáveis, eficazes e ágeis para evitar problemas futuros.

Embora os princípios gerem muitos benefícios, segui-los pode levar à escrita de códigos mais longos e complexos. Isso significa um processo de design mais estendido e o desenvolvimento um pouco mais difícil. Mas o esforço certamente vale a pena. Com SOLID, o software fica mais fácil de se manter, testar e ampliar.

O que é o conceito SOLID?

SOLID é um padrão de codificação em programação com regras gerais reunidas no artigo Princípios de projeto e padrões de projeto, publicado em 2000 por Robert Martin, conhecido como Uncle Bob, um entusiasta da comunidade de desenvolvimento de software, metodologias ágeis e artesanato de software.

O conceito foi desenvolvido posteriormente por Michael Feathers, especialista em Design de Software. Nos últimos 20 anos, os princípios revolucionaram o mundo da programação orientada a objetos, mudando a maneira como os códigos de software são escritos.

Quais são os 5 princípios SOLID?

Os cinco princípios SOLID tornam um código mais legível, fácil de manter e com padrões de design e testabilidade. São um conjunto de regras e práticas recomendadas a serem seguidas por desenvolvedores para atingir certos padrões de projeto e arquitetura de software em geral.

O acrônimo SOLID reúne as cinco principais premissas para o desenvolvimento eficaz de aplicativos:

• single responsibility;
• open-closed;
• Liskov substitution;
• interface segregation;
• dependency inversion.

Confira o que significa cada uma delas:

Single responsibility

O princípio de single responsibility foi introduzido pelo engenheiro de software Tom DeMarco em 1979 ao afirmar que “uma classe deve ter apenas um motivo para mudar”. Isso quer dizer que cada classe deve ter uma única responsabilidade, um único trabalho ou um único propósito.

No desenvolvimento de software, a tarefa precisa ser dividida em diferentes membros com funções específicas: designers de front-end projetam, testadores verificam o software e desenvolvedores de back-end cuidam dos bastidores do aplicativo. Assim, todos têm um único trabalho ou responsabilidade.

Open-closed

O open-closed, criado pelo consultor de linguagem de programação Bertrand Meyer em 1988, determina que “as entidades de software (classes, módulos, funções etc.) devem ser abertas para extensão, mas fechadas para modificação”. O uso desse princípio separa o código existente do código modificado para fornecer melhor estabilidade.

Os profissionais devem ser capazes de estender o comportamento de uma classe sem a modificar. Imagine que um desenvolvedor precise lançar uma atualização para uma biblioteca enquanto outro necessite adicionar algum recurso. O segundo desenvolvedor pode estender a classe existente criada, mas não deve modificá-la diretamente.

Liskov substitution

O princípio, introduzido pela cientista da computação Barbara Liskov em 1987, busca garantir que qualquer classe filha de uma classe pai possa ser usada no lugar do pai sem nenhum comportamento inesperado.

Um dos exemplos clássicos desse princípio é um retângulo. Os quatro lados do retângulo podem ter qualquer altura ou largura. Dessa forma, um quadrado pode ser considerado uma classe filha do retângulo, embora tenha largura e altura iguais. Assim, as propriedades da classe retângulo podem ser estendidas para a classe quadrado.

Para fazer isso, é necessário trocar a classe filha (quadrado) pela classe pai (retângulo) para se ajustar à definição de um quadrado com quatro lados iguais. No entanto, a classe derivada não afeta o comportamento da classe original.

Interface segregation

Formulado por Martin, o princípio de segregação de interface estabelece que os clientes não devem ser forçados a implementar uma interface irrelevante. Isso ajuda a evitar uma interface “abundante” para privilegiar interfaces pequenas específicas do cliente.

O objetivo desse princípio é reduzir os efeitos colaterais do uso de interfaces maiores, dividindo as interfaces do aplicativo em interfaces menores. É semelhante ao princípio da responsabilidade única, em que cada classe ou interface atende a um único propósito.

O design preciso do aplicativo e a abstração correta são a chave do princípio de segregação de interface. Embora leve mais tempo e esforço na fase de design de um aplicativo e possa aumentar a complexidade do código, no fim um código flexível é obtido.

Dependency inversion

Também criado por Martin, o princípio de inversão de dependência ajuda a acoplar os módulos de software livremente e é regido por duas regras básicas:

1. Os módulos de alto nível não devem importar nada dos módulos de baixo nível; ambos devem depender de abstrações.
2. As abstrações não devem depender de implementações concretas; implementações concretas devem depender de abstrações.

A abstração permite lidar apenas com a ideia geral de algo, sem se importar com os detalhes. Um carregador de notebook, por exemplo, pode ser conectado a qualquer tomada desde que o soquete satisfaça a “interface” dos três pinos. Dessa forma, o plugue pode ser utilizado em diversas tomadas desde que estas atendam aos requisitos da interface.

Quando usar SOLID?

SOLID deve ser aplicado por qualquer pessoa desenvolvedora de software. Inicialmente, pode ser complicado introduzir todas as regras no trabalho cotidiano, portanto é importante criar um sistema simples para começar a treinar e testar o uso de cada princípio.

A ferramenta é especialmente útil para isolar e testar funcionalidades, evitar duplicação e diminuir o risco de quebra de código após mudanças. O sistema permite que o software permaneça o máximo de tempo em utilização, com reaproveitamento da programação já realizada.