As variáveis e métodos estáticos em C# são ruins? Derek Comartin explica (análise em vídeo)

O que torna um método estático problemático?

No início do vídeo, Derek explora um método estático chamado Is18YearsOrOlder. Este método recebe uma data de nascimento (DateTime birthDate) e verifica se a pessoa tem pelo menos 18 anos. Ele usa DateTime.UtcNow para comparar com a data atual. Simples, não é?

Mas, como Derek destaca, esse método não é determinístico. Aos 0:50, ele destaca que usar DateTime.UtcNow significa que o método retornará resultados diferentes dependendo de quando for executado. Esse é um problema grave em testes unitários e causa comportamentos inesperados no código.

Neste caso, embora o método pareça uma função pura, não o é. Derek explica que um método puro deve retornar o mesmo valor sempre que for chamado com os mesmos parâmetros. Mas aqui, a data atual está sempre mudando, então o valor retornado também muda.

Isso ilustra como um método estático público, embora conveniente, pode introduzir efeitos colaterais se depender de dados em tempo real ou do estado do domínio da aplicação.

Tornando os métodos estáticos testáveis ​​e previsíveis

O próximo ponto de Derek é crucial: podemos corrigir o não determinismo removendo a dependência de DateTime.UtcNow. Em vez disso, Derek mostra como injetar um provedor de tempo usando uma classe estática ou uma implementação de interface. Isso torna a função determinística — você obtém a mesma saída sempre que passa a mesma entrada.

Em sua aula PlaceOrder, ele introduz um provedor de datas fictício para poder testar se os pedidos processados ​​às sextas-feiras recebem um desconto de 50%. Isso evita a codificação rígida de lógica vinculada ao horário do sistema, tornando o método mais confiável e testável.

Ao isolar o comportamento e evitar referenciar métodos estáticos diretamente na lógica de negócios, Derek mostra como preservar um código limpo, mantendo a testabilidade.

Acoplamento estreito e métodos estáticos

Neste ponto, Derek alerta que confiar em métodos estáticos frequentemente introduz um acoplamento forte. Se você usar diretamente DateTime.UtcNow, ficará vinculado a essa implementação — não poderá substituí-la nem criar mocks.

Isso é um problema porque membros estáticos como esse são globais em toda a sua aplicação. Se o seu código-fonte utiliza muitos campos ou propriedades estáticas, torna-se mais difícil alterar o comportamento ou injetar dependências, violando princípios fundamentais da programação orientada a objetos.

Você também perde flexibilidade porque não pode substituir esse campo estático por uma implementação diferente, como seria possível com uma variável de instância ou um serviço injetado.

O Problema do Estado Global com Variáveis ​​Estáticas

Agora Derek volta sua atenção para as variáveis ​​estáticas, e é aqui que a conversa fica séria.

Ele apresenta um exemplo utilizando um cache estático em uma classe Global. Ele explica que o maior problema com variáveis ​​estáticas é o estado desconhecido. Em tempo de execução, você não pode ter certeza se seu campo estático foi inicializado. Essa imprevisibilidade é especialmente arriscada quando há um nome de inteiro ou string estático e mutável envolvido.

Esse cenário piora quando os desenvolvedores presumem que existe apenas uma cópia dessa variável compartilhada entre as threads — e se esquecem de levar em conta a segurança de threads.

Segurança de threads e campos estáticos em código multithread

Derek levanta outra preocupação: o uso de variáveis ​​estáticas em ambientes multithread. Ele dá um exemplo de uma lista estática. usado simultaneamente com Parallel.For. O código falha porque o campo estático não é thread-safe.

Para resolver isso, ele muda para um ConcurrentBag. , uma coleção thread-safe disponível no .NET. Isso permite o acesso seguro aos dados estáticos em várias threads.

O ponto dele é claro: se você estiver usando variáveis ​​estáticas em diferentes threads, certifique-se de que elas sejam thread-safe. Caso contrário, seu programa pode se comportar de forma imprevisível ou até mesmo travar.

Uso seguro de métodos estáticos

Derek então compartilha um uso seguro e eficaz de um método estático: um método utilitário simples chamado MilesToKilometers. A função recebe um valor inteiro miles e retorna um valor do tipo double após a conversão. Este método é determinístico — para o mesmo valor inteiro, você sempre obterá o mesmo resultado.

Esse tipo de método não depende de campos não estáticos, não altera dados compartilhados e não envolve nenhum estado desconhecido. É um ótimo exemplo de como usar corretamente a palavra-chave static em C#.

Entendendo o Static no Contexto .NET

Em C#, a palavra-chave static pode ser aplicada a classes, campos, métodos, construtores e propriedades. Derek aborda indiretamente o conceito de:

• Classe estática: Uma classe que não pode ser instanciada e só pode conter membros estáticos.

• Campos estáticos: Declarados com a palavra-chave static — existe apenas uma cópia por domínio de aplicação.

• Construtor estático: Executa apenas uma vez, quando a classe é acessada pela primeira vez.

• Static void Main: O ponto de entrada da maioria das aplicações C#, demonstrando como os métodos estáticos podem ser essenciais.

• static int, static string: Exemplos de campos estáticos que armazenam dados comuns a todas as instâncias da classe ou, na verdade, que não exigem uma instância.

Ao contrário dos construtores de instância, que são executados sempre que você cria um objeto, o construtor estático inicializa os recursos de nível de classe apenas uma vez.

Essa distinção ajuda os desenvolvedores a decidir quando usar variáveis ​​de instância em vez de variáveis ​​estáticas, ou quando usar acessadores de propriedade para encapsular variáveis ​​de membro compartilhadas.

Considerações finais de Derek

Derek resume os principais motivos pelos quais os desenvolvedores alertam contra membros estáticos:

• Acoplamento forte — você fica preso ao comportamento desse método ou campo estático.

Comportamento não determinístico — difícil de testar, fácil de quebrar.

• Estado global mutável — você não sabe qual é o valor nem quem o alterou.

• Problemas de concorrência — acesso inseguro a dados compartilhados em código multithread.

No entanto, como diz Derek, a estática não é má. É uma ferramenta poderosa quando usada corretamente — especialmente em funções utilitárias, constantes compartilhadas ou configurações verdadeiramente globais. Basta gerenciar o estado com cuidado e evitar depender de comportamentos mutáveis ​​ou específicos do sistema.

Conclusão

Variáveis ​​e métodos estáticos são uma faca de dois gumes em C#. Como Derek Comartin explica claramente, elas não são inerentemente ruins — mas exigem um uso criterioso. Utilize campos estáticos e classes estáticas quando precisar de dados ou funcionalidades compartilhadas que não dependam do estado do objeto. Mas evite usá-los para tarefas que dependem de tempo, estado do sistema ou que exigem flexibilidade.

Portanto, antes de criar um objeto ou acessar um campo estático, pense no escopo, na testabilidade, na segurança de threads e se o código precisa de uma única cópia ou de múltiplas instâncias.

Assista ao vídeo completo de Derek Martin em seu canal do YouTube, CodeOpinion . Você encontrará mais informações sobre arquitetura limpa, design de software e aplicações C# do mundo real.