O método pode se tornar estático, mas deveria?

Question

O Resharper gosta de apontar várias funções por página asp.net que podem se tornar estáticas.Isso me ajuda se eu os tornar estáticos?Devo torná-los estáticos e movê-los para uma classe utilitária?

Answer 1

Métodos estáticos versus métodos de instância
10.2.5 membros estáticos e de instância da especificação de idioma C# explica a diferença. Geralmente, os métodos estáticos podem fornecer um aprimoramento de desempenho muito pequeno em relação aos métodos de instância, mas apenas em situações um tanto extremas (ver esta resposta Para mais alguns detalhes sobre isso).

Regra CA1822 em estados de análise de código ou código FXCOP:

"Depois de [marcar os membros como estática], o compilador emitirá sites de chamadas não virtuais para esses membros, o que impedirá um cheque em tempo de execução para cada chamada que garante que o ponteiro de objeto atual seja nulo. Isso pode resultar em um ganho de desempenho mensurável Para o código sensível ao desempenho. Em alguns casos, a falha em acessar a instância atual do objeto representa um problema de correção. "

Classe de utilidade
Você não deve movê -los para uma classe de utilidade, a menos que faça sentido em seu design. Se o método estático se refere a um tipo específico, como um ToRadians(double degrees) O método refere -se a uma classe que representa ângulos, faz sentido que esse método exista como um membro estático desse tipo (observe, este é um exemplo complicado para fins de demonstração).

Answer 2

Desempenho, poluição por namespace etc são todos secundários na minha opinião. Pergunte a si mesmo o que é lógico. O método está operando logicamente em uma instância do tipo ou está relacionado ao próprio tipo? Se for o último, faça -o um método estático. Apenas mova -o para uma classe de utilidade se estiver relacionada a um tipo que não estiver sob seu controle.

Às vezes, existem métodos que agem logicamente em uma instância, mas não usam nenhum estado da instância ainda. Por exemplo, se você estivesse construindo um sistema de arquivos e teria o conceito de diretório, mas ainda não o havia implementado, poderia escrever uma propriedade retornando o tipo de objeto do sistema de arquivos, e sempre seria apenas "FILE" - mas está logicamente relacionado à instância e, portanto, deve ser um método de instância. Isso também é importante se você deseja tornar o método virtual - sua implementação específica pode não precisar de estado, mas as classes derivadas podem. (Por exemplo, perguntar a uma coleção se é somente leitura-você pode não ter implementado uma forma somente leitura dessa coleção, mas é claramente uma propriedade da própria coleção, não do tipo.)

Answer 3

Marcando um método como static Dentro de uma aula, torna óbvio que ela não usa nenhum membro da instância, o que pode ser útil saber ao percorrer o código.

Você não precisa necessariamente movê-lo para outra classe, a menos que seja para ser compartilhado por outra classe que é tão intimamente associada, em termos de conceito.

Answer 4

Tenho certeza de que isso não está acontecendo no seu caso, mas um "cheiro ruim" que vi em alguns códigos que tive que sofrer para manter usava muitos métodos estáticos.

Infelizmente, eram métodos estáticos que assumiam um estado específico do aplicativo.(com certeza, teremos apenas um usuário por aplicativo!Por que a classe User não acompanha isso em variáveis ​​estáticas?) Elas eram formas glorificadas de acessar variáveis ​​globais.Eles também tinham construtores estáticos (!), que quase sempre são uma má ideia.(Eu sei que há algumas exceções razoáveis).

No entanto, os métodos estáticos são bastante úteis quando levam em consideração a lógica de domínio que na verdade não depende do estado de uma instância do objeto.Eles podem tornar seu código muito mais legível.

Apenas certifique-se de colocá-los no lugar certo.Os métodos estáticos estão manipulando intrusivamente o estado interno de outros objetos?Pode-se argumentar que o comportamento deles pertence a uma dessas classes?Se você não estiver separando as preocupações corretamente, poderá ter dores de cabeça mais tarde.

Answer 5

Esta é uma leitura interessante:

http://thecuttingledge.com/?p=57

O Resharper não está realmente sugerindo que você torne seu método estático. Você deve se perguntar por que esse método está nessa classe, em oposição a, digamos, uma das classes que aparecem em sua assinatura ...

Mas aqui está o que o Resharper Documentalion diz:http://confluence.jetbrains.net/display/resharper/member+can+be+Made+static

Answer 6

Apenas para adicionar ao @jason true's responda, é importante perceber que apenas colocar 'estático' em um método não garante que o método seja 'puro'. Será sem estado em relação à classe em que é declarada, mas pode acessar outros objetos 'estáticos' que têm estado (configuração do aplicativo etc.), isso nem sempre é uma coisa ruim, mas uma das razões que Pessoalmente, tendem a preferir métodos estáticos quando posso, se eles forem puros, você pode testar e raciocinar sobre eles isoladamente, sem ter que se preocupar com o estado circundante.

Answer 7

Você deve fazer o que é mais legível e intuitivo em um determinado cenário.

O argumento de desempenho não é bom, exceto nas situações mais extremas, pois a única coisa que está realmente acontecendo é que um parâmetro extra (this) está sendo empurrado para a pilha, por exemplo, métodos.

Answer 8

Para uma lógica complexa em uma classe, achei métodos estáticos privados úteis na criação de lógica isolada, na qual as entradas da instância são claramente definidas na assinatura do método e nenhum efeito colateral de instância pode ocorrer. Todas as saídas devem ser por meio de parâmetros de retorno ou saída/ref. Quebrando a lógica complexa em blocos de código sem efeito colateral pode melhorar a legibilidade do código e a confiança da equipe de desenvolvimento nele.

Por outro lado, pode levar a uma classe poluída por uma proliferação de métodos de utilidade. Como de costume, a nomeação lógica, a documentação e a aplicação consistente de convenções de codificação em equipe podem aliviar isso.

Answer 9

Resharper não verifica a lógica. Ele apenas verifica se o método usa membros da instância. Se o método for privado e chamado apenas por (talvez apenas um) métodos de instância, isso é um sinal para deixar um método de instância.

Answer 10

Se as funções forem compartilhadas em muitas páginas, você também poderá colocá -las em uma classe de página base e, em seguida, ter todas as páginas do ASP.NET usando essa funcionalidade herdada dela (e as funções ainda podem ser estáticas).

Answer 11

Fazer um método estático significa que você pode chamar o método de fora da classe sem primeiro criar uma instância dessa classe. Isso é útil ao trabalhar com objetos ou complementos de fornecedores de terceiros. Imagine se você tivesse que primeiro criar um objeto de console "CON" antes de ligar para o Con.WriteLine ();

Answer 12

Ajuda a controlar a poluição do espaço para nome.

Answer 13

Apenas meus dois centavos:Adicionar todos os métodos estáticos compartilhados a uma classe de utilitário permite adicionar

using static className; 

às instruções using, o que torna o código mais rápido de digitar e mais fácil de ler.Por exemplo, tenho um grande número do que seria chamado de "variáveis ​​globais" em algum código que herdei.Em vez de criar variáveis ​​globais em uma classe que era uma classe de instância, defini todas elas como propriedades estáticas de uma classe global.Ele faz o trabalho, embora confuso, e posso apenas referenciar as propriedades pelo nome porque já tenho o namespace estático referenciado.

Não tenho ideia se isso é uma boa prática ou não.Tenho tanto a aprender sobre C# 4/5 e tanto código legado para refatorar que estou apenas tentando deixar as dicas do Roselyn me guiarem.

Joey