image

Acesse bootcamps ilimitados e +650 cursos

50
%OFF
Article image
Luiz Freitas
Luiz Freitas03/11/2025 17:46
Compartilhe

O que Aprendi com o SOLID: Como Escrever Código que Resiste ao Tempo

    Sabe aquele código que você escreveu há 6 meses e hoje não faz ideia de como funciona?

    Ou pior: aquele sistema que basta adicionar uma vírgula para tudo desmoronar?

    Durante o Bootcamp TQI, aqui na DIO, concluí o curso "SOLID e Clean Code em Java: Escrevendo Código de Alta Qualidade", e descobri que a diferença entre código que envelhece bem e código que vira legado morto está em cinco princípios simples.

    Mesmo vindo do universo Delphi, percebi algo transformador: SOLID não é sobre Java, Python ou Go. É sobre mentalidade.

    O Código que Refatorei sem Tocar Nele

    O instrutor apresentou um sistema de controle de estoque de cestas básicas. Funcional? Sim. Sustentável? Nem um pouco.

    Então ele fez algo genial: refatorou o sistema aplicando os princípios do SOLID.

    Foi como assistir um mestre carpinteiro transformar tábuas toscas em mobília elegante, sem mudar a madeira, apenas o jeito de encaixá-la.

    E ali entendi: código de qualidade não é sobre fazer funcionar. É sobre fazer durar.

    Os 5 Princípios que Mudaram Minha Visão

    🎯 S: Responsabilidade Única

    "Uma classe, um propósito"

    Imagine um canivete suíço que também é martelo, furadeira e liquidificador. Não faz sentido, certo?

    Antes:

    class Estoque {
      void atualizarEstoque() { }
      void gerarRelatorio() { }
      void registrarVenda() { }
    }
    

    Depois:

    class EstoqueService { void atualizarEstoque() { } }
    class RelatorioService { void gerarRelatorio() { } }
    class VendaService { void registrarVenda() { } }
    

    Cada classe agora tem uma única razão para existir. Se o relatório mudar, não mexo no estoque. Simples assim.

    🚪 O: Aberto/Fechado

    "Estenda sem quebrar"

    Lembra quando você adiciona uma funcionalidade e três outras param de funcionar? O princípio Aberto/Fechado resolve isso.

    Exemplo em JavaScript:

    class Desconto {
    calcular(valor) { return valor; }
    }
    ​
    class DescontoNatal extends Desconto {
    calcular(valor) { return valor * 0.9; }
    }
    ​
    class DescontoClienteFiel extends Desconto {
    calcular(valor) { return valor * 0.85; }
    }
    

    Adicione quantos descontos quiser — o código original permanece intocado.

    🔄 L: Substituição de Liskov

    "Se parece pato, grasna como pato..."

    Subtipos devem substituir seus tipos base sem quebrar o sistema.

    Em Go (que uso nos meus estudos):

    type Repositorio interface {
      Salvar(dado string)
    }
    ​
    type RepositorioSQL struct{}
    func (r RepositorioSQL) Salvar(dado string) { 
      fmt.Println("Salvando em SQL") 
    }
    ​
    type RepositorioMemoria struct{}
    func (r RepositorioMemoria) Salvar(dado string) { 
      fmt.Println("Salvando em Memória") 
    }
    

    Tanto faz qual repositório você usa — o contrato é respeitado.

    ✂️ I: Segregação de Interface

    "Não force ninguém a implementar o que não usa"

    Interfaces grandes são como contratos leoninos: você assina tudo, mas só precisa de metade.

    Em Python:

    class RepositorioLeitura:
      def listar(self): pass
    ​
    class RepositorioEscrita:
      def salvar(self, dado): pass
    

    Quem só lê dados não precisa implementar escrita. Coesão no design.

    🔁 D: Inversão de Dependência

    "Dependa de abstrações, não de implementações"

    Este é o que mais me impactou, porque muda completamente a arquitetura.

    Em Delphi (minha base):

    type
    IRepositorio = interface
      procedure Salvar(Dado: string);
    end;
    ​
    TServico = class
    private
      FRepo: IRepositorio;
    public
      constructor Create(ARepo: IRepositorio);
      procedure Executar;
    end;
    

    Agora meu serviço não "conhece" o banco de dados. Ele conhece uma promessa de comportamento. Isso torna testes, manutenção e substituição infinitamente mais simples.

    O que Isso Muda na Prática

    Assistir a refatoração do sistema de estoque foi revelador. O código:

    • Antes: monolítico, acoplado, teste? Impossível.
    • Depois: modular, testável, legível como prosa.

    E não foi magia. Foi aplicação disciplinada de princípios.

    O SOLID que Transcende o Código

    Algo curioso aconteceu enquanto estudava. Percebi que cada princípio reflete valores que também carrego na vida:

    • Responsabilidade única → Foco e propósito
    • Aberto/fechado → Crescer sem perder essência
    • Substituição → Coerência e consistência
    • Segregação → Clareza e simplicidade
    • Inversão → Confiar em fundamentos sólidos

    E como tudo que aprendo, reconheço que a sabedoria vem do Alto. O Senhor Jesus me ensina a construir não apenas código, mas uma vida: com propósito, integridade e amor pelo próximo.

    E Você?

    Já aplicou SOLID no seu dia a dia? Que princípio mais te desafia?

    E se ainda não aplicou, qual deles faria diferença hoje no seu projeto?

    Comenta aí, quero ouvir sua experiência! 👇

    Compartilhe
    Recomendados para você
    Binance - Blockchain Developer with Solidity 2025
    Neo4J - Análise de Dados com Grafos
    Cognizant - Mobile Developer
    Comentários (0)