Criar muitas classes estáticas impacta na performance do sistema? – c# desempenho estilo-de-codificação
Pergunta:
Eu ando criando muitas classes estáticas para facilitar e limpar o código, como por exemplo uma chamada de API do Google Translate.
public static class GoogleTranslate
{
public static string Translate(string word){
//código de chamada
}
}
Fazendo assim fica muito mais fácil pois é só chamar:
GoogleTranslate.Translate("StackOverflow é a melhor universidade do mundo");
Eu tenho bastante classes assim para chamar APIS, como isso é visto diante dos profissionais?
Autor da pergunta Leonardo Bonetti
Maniero
Sim, fica mais rápido, classes estáticas não precisam instanciar, que tem um custo nada trivial.
Métodos estáticos são como funções normais de qualquer linguagem, está lá pronto para uso. A vantagem é que ela tem um sobrenome (é praticamente um namespace), então organiza melhor o código. Não precisa alocar nada (classe normal há alocação mesmo sem ter estado), não tem mecanismos sofisticados. Em classes estáticas todos os métodos devem ser estáticos.
Parece algo muito diferente, mas todas linguagens que não tentaram se vender como 100% orientada a objeto, que é uma falácia, sempre tiveram e sempre foi útil e deu certo.
O ganho é mais pelo método estático do que pela classe. Vale também para os métodos estáticos de classes quem podem ser instanciadas.
Existem outras características de classes estáticas, mas não são relevantes e muitas vezes até ruins.
Uma delas é a construção dela. Ela ocorre em algum momento antes de ser necessária (pode não ser na carga, mas pode ser, por isto uma técnica de lazy loading pode ser interessante). Precisa se certificar que a forma codificada atende tudo bem, que não exagera na carga do sistema (raramente ocorre), é preciso entender todas implicações para usar corretamente. Idealmente não deve ter uma construção, mas pode se for necessário, útil e souber o que está fazendo.
Quem gosta de OOP diz que não deve usar, eu venho de uma escola mais pragmática que faz o que deve fazer.
É mais difícil testar, mas não impossível. Eu prefiro dificultar o teste do que dificultar o código principal para facilitar o teste.
Se um dia precisar mudar a estratégia dinamicamente pode se tornar um problema, que é a mesma questão do teste. Se não é algo universal e único a instância pode ser uma opção melhor.
Cuidado com estado global variável na classe estática ou normal. Isto funciona bem em raros casos e precisa saber o que está fazendo. Não crie uma classes estática quando o adequado é uma instância. Se tem estado que potencialmente varia a cada execução, crie uma instância.
Eu e o Stack Overflow abusamos de classes estáticas 🙂 Muitos dizem que isso é um erro terrível, mesmo eles não sabendo do nosso contexto. Quando tem que ser uma instância, eu o faço. Na maior parte das vezes se um dia eu precisar mudar, eu refatoro (eu posso fazer isto, nem todo mundo pode), mesmo nos casos que dão trabalho refatorar, costuma compensar pelo ganho porque em quase todos os casos eu nunca precisei refatorar.



