🚀 O seu código é Orientado a Objetos ou apenas um "Procedural Disfarçado"?
Vamos tocar na ferida: o que mais existe por aí é o famoso "Código de Estimação". Aquele código empacotado em classes, cheio de getters e setters para todo lado, mas sem um pingo de inteligência ou comportamento real.
Se o código procedural resolve o problema e entrega o software, por que se dar ao trabalho de modelar objetos? A resposta não está na execução, mas na sustentabilidade.
Por que a OO (bem feita) salva o seu projeto?
Controle da Complexidade (O fim do Espaguete): No procedural, os dados são passivos e as funções globais. Conforme o sistema cresce, mexer em um ponto quebra cinco outros lugares imprevisíveis. A OO propõe o Encapsulamento: cada objeto é uma "caixa preta" que cuida da própria vida.
Flexibilidade sem Cirurgia (Polimorfismo): Precisa adicionar um novo meio de pagamento (ex: Cripto)? Em vez de espalhar
if/elsepor todo o sistema, você apenas cria um novo objeto que sabe "Processar". Você adiciona funções sem tocar no que já está funcionando.
🏛️ Os 4 Pilares na Prática
| Pilar | O que resolve na vida real? |
|---|---|
| Abstração | Esconde a complexidade. Você dirige o carro sem precisar entender a explosão interna do motor. |
| Encapsulamento | Protege os dados. Ninguém altera o "Saldo" sem passar pelas regras de negócio. |
| Herança | Compartilha características comuns, evitando redundância (mas cuidado para não virar um pesadelo!). |
| Polimorfismo | Permite que diferentes objetos respondam à mesma mensagem de formas específicas. |
💡 O Veredito
Usamos Orientação a Objetos para que o código seja legível para humanos, e não apenas compreensível para máquinas. O custo de manutenção de um software é, em média, 80% do seu ciclo de vida.
A OO bem aplicada é um investimento para que o desenvolvedor do futuro (que pode ser você daqui a seis meses) não queira deletar tudo e começar do zero.
E aí, o seu código atual passaria em um teste de pureza de OO? 🧐
#programação #softwareDevelopment #cleanCode #OOP #devLife #brazilianDevs
Top comments (6)
Em muitos projetos a orientação a objetos vira apenas uma estrutura de pastas e classes, mas a lógica continua totalmente procedural. No mundo .NET, é fácil cair na armadilha de criar classes só por criar, sem pensar no comportamento real dos objetos. O encapsulamento e o polimorfismo são, sem dúvida, os pilares que mais salvam o nosso dia a dia na hora de escalar
Concordo muito com isso.
Vejo bastante código orientado a objetos que, na prática, só mudou a sintaxe — sai o
procedure.No .NET isso acontece com frequência, principalmente quando a arquitetura vira apenas separação em camadas (Controller, Service, Repository), sem que os objetos realmente tenham responsabilidade e comportamento próprios.
Pra mim, encapsulamento e polimorfismo são realmente os pilares que mais fazem diferença no dia a dia, porque são eles que permitem evoluir o sistema sem quebrar tudo.
Quando o objeto só tem getter/setter e não tem regra dentro dele, a gente perde praticamente todos os benefícios da POO.
Tenho tentado focar cada vez mais em modelar comportamento em vez de apenas estruturar classes.
Na sua experiência, em que momento você percebe que um projeto .NET começou a ficar procedural mesmo estando todo orientado a objetos?
Obrigado pelo comentário!
É importante lembrar que usar a abordagem certa e manter o código simples ajuda muito na manutenção futura, além de facilitar o entendimento rápido do código kkkkk.
Com certeza kkkkk.
Código simples hoje é manutenção fácil amanhã… código complicado hoje é o dev do futuro xingando seu nome no commit history.
Acho que o difícil é justamente achar o equilíbrio, porque no .NET é muito fácil sair criando camada, interface, factory, strategy, adapter… e quando vê o CRUD virou uma arquitetura de foguete da NASA.
No fim das contas, quando a regra de negócio está bem modelada e os objetos realmente têm responsabilidade, o código fica muito mais natural de entender, até pra quem nunca viu o projeto antes.
Agora fiquei curioso: qual foi o pior caso de “overengineering” que você já encontrou em um projeto?
Obrigado pelo comentário!
Excelente post! Muita gente acha que está fazendo OO, mas no fundo é só procedural dentro da classe. A diferença aparece quando os objetos realmente carregam comportamento, não só dados.
Valeu mesmo! Fico feliz que você comentou isso, porque é exatamente esse ponto que eu quis trazer no post.
Muita gente (eu inclusive no começo) acha que está fazendo orientação a objetos só porque colocou tudo dentro de classe, mas quando você olha de perto, a lógica continua procedural, só que distribuída em vários arquivos. A diferença aparece de verdade quando os objetos começam a ter comportamento próprio e a regra de negócio não fica toda concentrada em service ou helper.
Quando o objeto só carrega dados, a gente perde quase todos os benefícios da OO, e o código fica difícil de evoluir sem quebrar algo.
Obrigado pelo comentário! É muito bom ver mais gente com essa mesma preocupação com modelagem de verdade.