Aprendendo SOLID: Princípios para um código sustentável e de qualidade

Como desenvolvedor de software, estou sempre buscando maneiras de aprimorar minhas habilidades e escrever um código melhor. Recentemente, decidi aprender os princípios do SOLID.

SOLID é um acrônimo que representa cinco princípios de design de código orientado a objetos. Esses princípios foram introduzidos por Robert C. Martin (também conhecido como Uncle Bob) no início dos anos 2000 e se tornaram amplamente adotados na comunidade de desenvolvimento de software. O objetivo do SOLID é criar um código mais sustentável, flexível e de fácil manutenção.

Os cinco princípios do SOLID

Single Responsibility Principle (SRP) - Princípio da Responsabilidade Única
- Uma classe deve ter apenas uma única responsabilidade, ou seja, deve haver apenas uma razão para uma classe mudar.
- Isso torna o código mais modular, focado e fácil de entender.
- Estou começando a ver como dividir classes grandes em partes menores e mais focadas pode melhorar muito a legibilidade e a manutenção do meu código.
- Isso pode significar:
  - Dividir controllers grandes em controllers menores, cada um responsável por um conjunto específico de ações.
  - Mover lógica de negócios dos controladores para os modelos ou serviços.
Open-Closed Principle (OCP) - Princípio Aberto-Fechado
- As entidades de software (classes, módulos, funções, etc.) devem estar abertas para extensão, mas fechadas para modificação.
- Isso significa que você deve ser capaz de estender o comportamento de uma classe sem modificar seu código fonte.
- Este princípio me fez repensar como estruturo minhas classes e como posso usar herança e composição para tornar meu código mais flexível.
- Isso pode envolver:
  - Usar concerns para compartilhar comportamentos entre modelos.
  - Usar decorators para estender os models sem modificá-los diretamente.
Liskov Substitution Principle (LSP) - Princípio da Substituição de Liskov
- Subclasses devem ser substituíveis por suas classes base.
- Isso garante que uma subclasse possa ser usada em qualquer lugar onde sua classe base é esperada, sem quebrar o comportamento do programa.
- Estou começando a entender a importância de projetar hierarquias de classes robustas que aderem a este princípio.
- Um exemplo poderia ser:
  - Se você tiver um model User e um model Admin que herda de User, qualquer código que espere um User deve ser capaz de lidar com um Admin sem problemas.
Interface Segregation Principle (ISP) - Princípio da Segregação de Interface
- Os clientes não devem ser forçados a depender de interfaces que não usam.
- É melhor ter muitas interfaces específicas do que uma interface geral.
- Este princípio me ensinou a pensar cuidadosamente sobre como projeto minhas interfaces para que sejam focadas e fáceis de usar.
- Isso pode significar:
  - Dividir um model grande em concerns menores, cada um com uma interface focada.
Dependency Inversion Principle (DIP) - Princípio da Inversão de Dependência
- Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.
- Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.
- Este foi talvez o princípio mais desafiador para mim entender, mas estou começando a ver como ele pode tornar meu código mais flexível e testável.
- Isso pode envolver:
  - Usar interfaces (ou concerns) para desacoplar as classes.
  - Usar injeção de dependência para dar às classes suas dependências, em vez de criá-las diretamente.

Aplicando SOLID na prática

Dominar os princípios SOLID leva tempo e prática. Aqui estão algumas coisas que tento sempre pensar quando estou desenvolvendo:

Comece pequeno: Tente aplicar um princípio de cada vez em seu código. À medida que você se sentir mais confortável, adicione outros.
Refatore regularmente: Reserve um tempo para revisar seu código e identificar oportunidades de aplicar os princípios SOLID.
Estude exemplos: Procure exemplos de código que demonstrem os princípios SOLID em ação. Aprenda com a experiência de outros desenvolvedores.