Princípio DRY em C#: Por que a duplicação de código prejudica sua base de código – Explicado por Derek Comartin

Definição do Princípio DRY

No início do vídeo, Derek descreve o contexto que muitos desenvolvedores enfrentam: lidar com um sistema difícil de modificar — uma complexa mistura de código repetido e lógica redundante.

Ele apresenta o princípio DRY (Don't Repeat Yourself) em C# como uma estratégia para reduzir a repetição de código, mas alerta que ele é frequentemente mal interpretado. Como Derek explica aos 0:28:

"Quando o princípio DRY é aplicado com sucesso, uma modificação em qualquer elemento individual do sistema não exige uma alteração em nenhum elemento logicamente não relacionado."

Essa distinção é crucial. O princípio DRY visa não apenas evitar código duplicado, mas também promover a separação de responsabilidades e a reutilização adequada de código — resultando em código limpo e de fácil manutenção, que é mais fácil de testar e refatorar.

Exemplo prático: Conversão de distância

Para tornar as coisas tangíveis, Derek oferece um exemplo simples em C#. Ele descreve dois métodos:

• Distância de envio

• Distância do pedágio

Cada um calcula as distâncias em milhas e depois as converte para quilômetros — usando a mesma lógica em ambos os métodos. Isso é um caso clássico de duplicação de código.

Em vez de ter o mesmo trecho de código em vários lugares, Derek mostra como você pode extrair a lógica de conversão para um método privado — MilesToKilometers() — uma maneira básica, porém eficaz, de refatorar o código para reutilização.

Ele ilustra isso usando a estrutura típica de um aplicativo de console: uma classe Program com um método estático void Main. É o tipo de estrutura que muitos desenvolvedores usam ao testar lógica ou experimentar um novo cenário de entrada do usuário, como public int age, string username, string password, etc.

SECO vs. Acoplamento Excessivo

Embora abstrair a lógica em um método reutilizável ou em uma classe separada pareça ideal, Derek recomenda cautela. O uso excessivo do princípio DRY, especialmente em toda uma aplicação, pode levar a níveis perigosos de acoplamento.

Por exemplo, se você inserir a lógica de conversão em um utilitário compartilhado usado por vários projetos e, posteriormente, alterar seu comportamento de arredondamento ou precisão decimal, a alteração poderá afetar inesperadamente diversas áreas. Como Derek disse às 2:31:

Os clientes esperam duas casas decimais? O que acontece se mudarmos para zero?

Essa é uma preocupação transversal — lógica reutilizada por muitas partes do sistema — e ilustra o risco de centralizar muito cedo ou sem limites claros.

O conselho de Derek aqui ecoa o Princípio da Responsabilidade Única e o Princípio da Inversão de Dependência, dois outros princípios SOLID cruciais para manter seu código adaptável e modular.

Inchaço de código devido à implementação incorreta do DRY (Don't Repeat Yourself).

Outro problema com o uso indevido do princípio DRY é o inchaço do código — onde a tentativa de abstrair tudo leva a classes utilitárias inchadas ou métodos excessivamente genéricos. Derek alerta que o excesso de lógica DRY (Don't Repeat Yourself - Não se Repita) pode causar mais danos do que benefícios, especialmente em sistemas grandes onde correções de bugs em uma área podem quebrar outras devido a dependências compartilhadas.

Segundo Derek, a chave é saber quando não compartilhar código — especialmente se isso resultar em módulos fortemente acoplados. "Seco" não é uma regra; É uma diretriz que deve ser usada dentro de um contexto.

Princípio DRY aplicado a entidades: uma receita para a complexidade

Derek identifica uma tendência comum entre desenvolvedores: organizar sistemas inteiramente em torno de entidades como Caminhão, Pedido, Motorista e Remessa. Embora seja tentador reutilizar a mesma classe ou objeto em diferentes métodos, isso geralmente leva à repetição de conceitos e a um acoplamento indesejado.

Ele argumenta que as capacidades de negócio — e não apenas as estruturas de dados — devem orientar a arquitetura. Por exemplo, "despachar um pedido" é uma preocupação diferente de "desengatar um reboque", mesmo que envolvam as mesmas entidades.

Às 4h45, Derek explica:

"Uma única entidade em seu sistema não precisa ser uma representação de múltiplos conceitos."

Isso destaca uma percepção arquitetônica mais profunda: entidades com o mesmo nome (Veículo, Reboque) podem representar responsabilidades diferentes em fluxos de trabalho distintos. O uso intercambiável desses termos gera confusão e acopla fortemente lógicas de negócios não relacionadas.

DRY e Capacidades de Negócios

Para resolver isso, Derek apresenta a Arquitetura de Fatias Verticais (VSA, na sigla em inglês) — um padrão que estrutura aplicativos em torno de capacidades de negócios em vez de camadas. Cada "fatia" inclui tudo o que é necessário para uma ação ou caso de uso específico — da solicitação ao banco de dados — encapsulado e autocontido.

Ele enfatiza que o código DRY é bom dentro de uma fatia — dentro de um único local — mas aplicar o princípio DRY em várias fatias pode levar a dependências complexas. Às 6h44, ele acrescenta:

"Trata-se apenas de reduzir o acoplamento e aumentar a coesão..." E uma maneira de fazer isso é: não repita conceitos dentro de um mesmo limite."

Essa mentalidade orientada por limites lhe dá flexibilidade. Você pode ter um modelo de domínio completo em uma fatia e apenas um modelo de dados simplificado em outra. Depende das necessidades da fatia — uma abordagem pragmática alinhada com a filosofia do Programador Pragmático.

Considerações finais

Derek conclui reformulando o princípio DRY como uma ferramenta, não uma lei. Como ele mesmo disse às 7h:

"Trata-se apenas de entender como você está aplicando isso." Se você estiver aplicando isso em grande quantidade, poderá ter mais acoplamento."

Portanto, antes de extrair essa lógica de validação, string de conexão ou converter código repetitivo em um método separado, considere se isso realmente tornará toda a sua base de código mais fácil de manter — ou apenas mais difícil de modificar.

Conclusão

A análise de Derek Comartin sobre o princípio DRY em C# mostra como uma regra aparentemente simples pode ser contraproducente quando aplicada sem nuances. Ao analisar exemplos de código, discutir cenários práticos e enfatizar os princípios de design de software, ele revela o equilíbrio necessário entre reutilização e modularidade.

Para melhorar significativamente o seu processo de desenvolvimento, lembre-se:

• Utilize o princípio DRY (Don't Repeat Yourself) para refatorar código redundante dentro de limites claros.

• Não elimine entidades que servem a propósitos comerciais diferentes.

• Respeite o contexto ao centralizar a lógica — especialmente em vários locais ou projetos.

• Considere os testes unitários e como a injeção de dependência pode afetar o código compartilhado.

Ao aplicar essas lições, você escreverá um código C# mais eficiente, modular e fácil de manter — e evitará transformar sua base de código em um emaranhado de lógica duplicada e dependências complexas.

Você pode assistir ao vídeo completo de Derek Martin para obter mais informações no canal do CodeOpinion no YouTube .