Compreendendo os Principios SOLID

Os Princípios SOLID, introduzidos por Robert C. Martin, orientam o design de software para tornar o código mais legível e sustentável. Este artigo explora cada princípio, discutindo sua aplicação prática.

1. Responsabilidade Única (Single Responsibility Principle – SRP)

Princípio da Responsabilidade Única (SRP) nos diz que uma classe deve ter apenas uma responsabilidade, ou seja, fazer uma coisa bem feita. Isso simplifica o código, torna-o mais fácil de entender e manter. É como ter ferramentas em uma caixa, cada uma com sua função específica, facilitando o uso e evitando confusão. Em resumo, o SRP é a regra de ouro: uma classe, uma responsabilidade. Isso torna o desenvolvimento e a manutenção do código mais eficientes, mesmo para quem não tem conhecimento técnico.

Veja um exemplo abaixo:

Neste caso, a classe Pedido tem a responsabilidade de lidar com a lógica do pedido e também de enviar e-mails de confirmação. Podemos aplicar o SRP dividindo essas responsabilidades em classes separadas:

Agora, temos uma classe EmailService dedicada a lidar com o envio de e-mails de confirmação, seguindo o princípio de responsabilidade única.

2. Princípio Aberto/Fechado (Open/Closed Principle – OCP)

O Princípio Aberto/Fechado (OCP) diz que uma classe deve permitir a adição de novos comportamentos sem mudar o código original. Em vez de mexer no que já funciona, podemos ampliar a classe para incluir novas funcionalidades. Isso faz com que o sistema seja mais flexível e menos propenso a erros, facilitando a adaptação a novas necessidades. Em resumo, com OCP, podemos melhorar sem mexer no que já está funcionando.

Veja um exemplo abaixo:

Neste caso, vamos considerar um sistema de processamento de pagamentos com descontos para diferentes tipos de clientes. Este código viola o OCP, pois se quisermos adicionar um novo tipo de cliente, teríamos que modificar a classe. Podemos resolver isso usando polimorfismo e herança:

Agora, podemos adicionar novas implementações de ICalculadoraDesconto sem modificar a classe ProcessadorDePagamentos.

3. Princípio de Substituição de Liskov (Liskov Substitution Principle – LSP)

O Princípio da Substituição de Liskov (LSP) garante que as subclasses possam substituir suas classes base sem causar problemas no programa. Em outras palavras, se um objeto pertence a uma classe base, ele deve poder ser substituído por um objeto de uma classe derivada sem comprometer a integridade do programa. Isso assegura que a herança seja usada de maneira consistente, sem impactar a correção do código. Em resumo, com o LSP, podemos trocar partes do código sem quebrar nada.

Veja um exemplo abaixo:

Aqui, temos um problema. Se passarmos um objeto da classe Quadrado para o método ModificarRetângulo, ele pode modificar as propriedades Altura e Largura de maneira que não seja consistente com um quadrado, violando assim o LSP.

Aqui, reestruturamos as classes para evitar a violação do LSP. Agora, Quadrado não herda mais de Retângulo, mas ambos herdam de uma classe base mais genérica, Forma. Isso permite que as propriedades Altura e Largura sejam manipuladas de maneira apropriada para cada tipo de forma, respeitando o LSP.

4. Princípio da Segregação de Interface (Interface Segregation Principle – ISP)

O Princípio da Segregação de Interfaces (ISP) diz que uma classe não deve ser obrigada a implementar interfaces que ela não usa. Em outras palavras, em vez de impor uma única interface grande, crie interfaces mais específicas para diferentes contextos. Isso garante que uma classe só implemente o que realmente precisa, tornando o código mais limpo e coeso. Em resumo, com o ISP, evitamos obrigar uma classe a adotar funcionalidades que não são relevantes para ela.

Veja um exemplo abaixo:

Neste exemplo, a interface ITrabalhador inclui métodos para trabalhar, comer e dormir. No entanto, isso pode ser problemático, pois nem todas as classes que implementam ITrabalhador podem precisar de todas essas funcionalidades.

Aqui, as interfaces foram segregadas em ITrabalhador, IComedor e IDorminhoco. Agora, as classes podem implementar apenas as interfaces que são relevantes para elas. Isso evita que uma classe seja forçada a implementar métodos que não são necessários para sua funcionalidade, respeitando o Princípio da Segregação de Interfaces.

5. Inversão de Dependência (Dependency Inversion Principle – DIP)

O Princípio da Inversão de Dependência (DIP) diz que as classes de alto nível não devem depender diretamente das classes de baixo nível. Em vez disso, ambas devem depender de abstrações. Essa abordagem facilita a substituição de implementações e promove a flexibilidade do sistema. Resumindo, com o DIP, tornamos o sistema menos dependente de detalhes específicos de implementação, o que facilita a adaptação a mudanças.

Veja um exemplo abaixo:

Aqui, a classe Interruptor depende diretamente da classe de baixo nível Lampada. Isso viola o DIP, pois a classe de alto nível está fortemente acoplada à implementação específica da classe de baixo nível.

Agora, a classe Interruptor depende de uma abstração IDispositivoEletronico em vez de depender diretamente da implementação concreta Lampada. Isso respeita o DIP, pois as classes de alto e baixo nível dependem de abstrações, tornando o sistema mais flexível. Se precisarmos trocar a implementação de Lampada por outra classe que também implementa IDispositivoEletronico, podemos fazer isso sem afetar a classe Interruptor.

Conclusão

A utilização dos Princípios SOLID é uma boa prática, o que torna nosso código mais fácil de entender e manter. Em resumo, seguir esses princípios melhora a qualidade do código, tornando-o mais flexível e sustentável a longo prazo, independentemente das peculiaridades de cada projeto.