Questões Vitais de C#: Múltiplas Interfaces, Métodos Virtuais,

Múltiplas implementações de uma mesma interface: isso pode explodir seu código?

Quando você usa serviços de injeção de dependência em C#, pode ter várias classes que implementam a mesma interface. O que acontece se você registrar as duas implementações? Por padrão, muitas bibliotecas retornam só a última instância registrada ao resolver a interface — ou todas, como uma coleção, dependendo do método usado. Então, você deve ser explícito ao registrar e ao consumir: decida se precisa de uma instância específica, ou de todas.

Como escolher entre virtual, override e abstract em C#?

O modificador virtual permite que métodos sejam sobrescritos em classes filhas, mesmo em classes não abstratas. O override indica a sobrescrita efetiva em uma subclasse. O abstract obriga a sobrescrita em todas as subclasses e impede instância direta da classe base. Esses detalhes mudam como a lógica de negócio é herdada e redefinida.

Você sabe mesmo o que acontece ao sobrescrever métodos?

Instâncias de subclasses só usarão sua implementação sobrescrita se você marcar o método na base com virtual (ou abstract ). Métodos não marcados não podem ser sobrescritos. Em casos de hierarquia, diferentes tipos retornam comportamentos distintos dependendo da sobrescrita, permitindo regras específicas por classe.

Classes abstratas: bloqueio e obrigação com um só modificador

Marcar uma classe como abstract é obrigatório se ela possui métodos abstratos. Isso impede a criação direta de instâncias. Além disso, toda classe filha deverá implementar os métodos abstratos, fortalecendo a segurança e a segregação de responsabilidades no código.

É possível bloquear a herança em C#? Sim.

Ao utilizar o modificador sealed na classe, você impede totalmente que ela seja herdada. Isso protege implementações críticas contra extensões não autorizadas ou mal planejadas, especialmente em bibliotecas e SDKs.

Queries SQL direto da API: performance vs risco real

Escrever queries SQL direto na API traz controle absoluto e ganho de desempenho — a query roda exatamente como você deseja, evitando overhead do ORM. Mas o preço é alto: aumenta a responsabilidade do dev em garantir a segurança, a compatibilidade e a manutenção quando o banco ou o modelo muda.

Controle: quando é vantagem e quando vira armadilha?

Escrever SQL manualmente dá ajuste fino e resolve casos que ORMs simplificam demais. Porém, cada modificação em nome, tipo ou estrutura do banco exige atualização manual em todos os lugares no código onde o SQL aparece. O ganho de controle pode rapidamente virar acúmulo de erros e inconsistência.

Performance: SQL manual é mesmo mais rápido sempre?

Queries customizadas escapam do trabalho extra dos ORMs, o que — especialmente em bancos “feios” ou sem padronização — pode dar um salto enorme de performance. Mas, em bancos bem modelados, o ganho tende a ser pequeno ou nulo nas versões recentes dos frameworks.

Desvantagens do SQL manual: manutenção e padronização

Alterou o nome de uma coluna ou tabela? Munido só de queries soltas, cada trecho de código afetado precisa ser revisado um a um — diferente do ORM que propaga alterações de modelo automaticamente. Além disso, as nuances de cada banco podem fazer com que uma string SQL funcione em um e falhe em outro.

É seguro misturar queries puras e ORM?

Em muitos projetos maduros, é comum encontrar ambos (Dapper, ADO.NET com Entity Framework). Use queries puras para casos de alta performance (leitura gigante, relatórios), mas garanta que todo input do usuário seja parametrizado para não expor dados sensíveis.

Interface, abstract ou sealed? Decida com clareza

Use interface para contratos, abstract para modelos parcialmente implementados e sealed só para bloquear herança (exemplo: tipos utilitários, controladores finais). Seu projeto agradece e fica muito mais legível para todos e pronto para mudanças futuras.

Evite bug: domine o ciclo de vida de instâncias

Entenda como o container de injeção de dependência “enxerga” suas implementações e de que forma ele pode se confundir, retornando instâncias inesperadas (ou até lançando exceção). Checar o contexto e o escopo de resolução é obrigatório quando a interface recebe várias implementações.

Checklist do código seguro e futuro-proof: nunca ignore

1. Marque métodos com virtual só quando realmente vão ser sobrescritos. 2. Modifique a assinatura quando desejar garantir override obrigatório (abstract). 3. Use sealed caso precise frear herança. 4. Para queries, sempre use parâmetros, mantenha scripts versionados e crie testes automatizados para validar resultados de queries.

Resumo prático: o que você NÃO pode esquecer

Interfaces múltiplas obrigam registro explícito. Virtual e abstract não dependem um do outro, mas cada um serve a uma função diferente. Query na API não é atalho: é decisão de arquitetura que demanda disciplina extrema com validação e refatoração.

Quer avançar? Siga para mais (Dev Doido no YouTube)

Todos esses temas estão em vídeos detalhados, exemplos ao vivo e muito mais dicas no canal Dev Doido. Clique, inscreva-se e compartilhe com devs que querem aprender no detalhe — e não ficar na superficie!

Para quem acompanha o debate sobre data centers no Brasil, o portal <a href="https://datacenteruberlandia.com.br">datacenteruberlandia.com.br</a> reúne análises, documentos e atualizações sobre o licenciamento ambiental do maior projeto de data center de IA anunciado no país, em Uberlândia/MG.