Você não sabe SOLID

3/16/2026•Michael

E aí, galera.

Hoje vamos bater um papo sobre um assunto que todo dev acha que domina mas, na real, a maioria só decorou a sigla: SOLID.

Não estou dizendo que SOLID é inútil. Estou dizendo que a forma como a maioria usa é inútil.

A galera decora as cinco letras, cola num checklist de code review e acha que está fazendo arquitetura.

Não está. Está seguindo receita de bolo sem entender por que a farinha vai antes do ovo.

A tese aqui é provocação deliberada: quem pensa em arquitetura já aplica SOLID sem saber. E quem só sabe SOLID não sabe arquitetura. Se você discorda, ótimo — vou tentar te convencer ao longo do texto.

O que a galera chama de SOLID

Pergunta pra qualquer dev intermediário o que é SOLID.

Você vai ouvir:

  • S — uma classe faz só uma coisa
  • O — aberto pra extensão, fechado pra modificação
  • L — subclasse não pode quebrar o comportamento da classe pai
  • I — interface pequena é melhor que interface grande
  • D — dependa de abstração, não de implementação concreta

Tudo certo.

Agora pergunta como ele aplica no dia a dia.

Aí começa o problema.

Você vai ouvir coisas como "esse método tem 15 linhas, viola o SRP" ou "não posso mudar essa classe porque viola o OCP".

A sigla virou dogma. O princípio virou regra de lint mental.

Isso não é SOLID. Isso é superstição de dev.

SOLID é um guia, não uma lei

Robert Martin criou o SOLID pra ensinar desenvolvedores a escrever código que não vire uma bola de lama com o tempo. É um conjunto de heurísticas — não de leis imutáveis.

O problema é que heurística virou mandamento. E mandamento sem contexto é burrice organizada.

Tamanho de método não está em nenhuma das cinco letras. Cyclomatic complexity também não. "Essa classe faz duas coisas" é subjetivo — o que é uma coisa pra você pode ser meia coisa pra mim.

SOLID diz o que evitar.

Não diz como construir.

Quem pensa em arquitetura já aplica

Vamos pegar um exemplo real em Rails.

Você tem um sistema multi-tenant de gestão de times de esports.

Cada módulo — players, analytics, scouting, matches — tem seus próprios controllers, services, models, serializers e policies.

Você não pensou "vou aplicar o S do SOLID aqui". Você pensou "analytics não tem nada a ver com players, então ficam separados". O resultado é o mesmo — responsabilidade única — mas o raciocínio é arquitetural, não de checklist.

app/modules/
├── players/
│   ├── controllers/
│   ├── services/
│   ├── models/
│   └── policies/
├── analytics/
│   ├── controllers/
│   └── services/
└── scouting/
    ├── controllers/
    └── services/

S apareceu porque você pensou em domínio. I apareceu porque cada módulo expõe só o que precisa. D apareceu porque o controller não instancia o service diretamente — ele consome uma abstração.

Você aplicou quatro letras do SOLID sem abrir um artigo sobre SOLID.

O exemplo que expõe tudo

Sabe o que acontece quando alguém aplica SOLID sem pensar em arquitetura?

class PlayerStatsCalculator
  def calculate_kda(player); end
end

class PlayerKdaFormatter
  def format(kda); end
end

class PlayerKdaPresenter
  def present(kda); end
end

class PlayerKdaLogger
  def log(kda); end
end

"Cada classe faz uma coisa." SRP aplicado. SOLID satisfeito.

E você tem quatro classes pra fazer o que um método resolve:

def kda_summary(player)
  kills, deaths, assists = player.kills, player.deaths, player.assists
  kda = deaths.zero? ? (kills + assists).to_f : (kills + assists).to_f / deaths
  "#{player.name}: #{kda.round(2)}"
end

SOLID sem arquitetura é isso: complexidade sem propósito.

As letras que ninguém lembra — e o que isso revela

Se você for honesto, sabe S e I. Talvez D. O e L você lembra quando alguém pergunta, esquece na semana seguinte.

Não é coincidência. O e L são as letras que menos fazem sentido fora de um contexto de domínio bem modelado.

O OCP — aberto pra extensão, fechado pra modificação — só aparece naturalmente quando você já desenhou uma hierarquia de comportamento. No sistema de esports: você não modifica a lógica de cálculo de ranking toda vez que uma nova modalidade entra. Você estende. Mas pra chegar nessa decisão, você precisou primeiro entender que "modalidade" é um conceito do seu domínio que vai variar, crescer e se ramificar. Quem não pensou em domínio antes não tem onde encaixar o OCP — a letra flutua sem âncora.

O LSP — subclasse não pode quebrar o comportamento da classe pai — é ainda mais dependente de hierarquia bem pensada. Se você modelou herança por conveniência de reutilização de código em vez de por relação real entre conceitos do domínio, LSP vai ser violado quase por definição. A letra não conserta uma herança mal concebida. Ela só nomeia o sintoma.

É por isso que O e L somem da memória: sem domínio, elas não têm onde se apoiar.

Então pra que serve SOLID?

Serve pra quem está aprendendo a organizar código e precisa de referência. É um mapa pra iniciante — útil pra não se perder, mas não é o território.

Quando você já pensa em termos de domínio, bounded contexts, separação de responsabilidades por módulo, SOLID é consequência — não ponto de partida.

É como dirigir. No começo você pensa "espelho, seta, freio". Depois de anos, você só dirige. Os passos continuam acontecendo, mas viraram instinto. Quem ainda fica recitando os passos em voz alta provavelmente ainda está aprendendo.

Conclusão

O risco real do SOLID como checklist não é que ele produza código ruim. É que ele dá a sensação de que código bom foi produzido.

Você fragmenta classes, satisfaz as cinco letras, passa no code review — e entrega um sistema que ninguém consegue mudar sem medo, porque as peças foram cortadas no tamanho certo mas coladas no lugar errado.

Arquitetura é sobre onde as responsabilidades vivem em relação ao domínio. SOLID é sobre como essas responsabilidades se relacionam internamente. Um sem o outro é decoração.

Na próxima vez que alguém falar que seu método viola o SRP porque tem 15 linhas, pergunta de volta: "viola como? em relação a qual responsabilidade de domínio?"

Se a pessoa travar, você sabe quem realmente entende o princípio.

Você já parou de pensar em SOLID e começou a pensar em domínio? Como foi essa virada?

Me conta nos comentários.

Até a próxima.

Referências

Loading comments...