O método pode ser feito estático, mas deveria?

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 torná-los estáticos? Devo torná-los estáticos e movê-los para uma class de utilidade?

   

Métodos estáticos versus methods de instância
10.2.5 Os membros estáticos e de instância da Especificação da Linguagem C # explicam a diferença. Geralmente, os methods estáticos podem fornecer um aprimoramento de desempenho muito pequeno sobre os methods de instância, mas apenas em situações um pouco extremas (veja essa resposta para obter mais detalhes sobre isso).

A regra CA1822 nos estados FxCop ou Code Analysis:

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

Classe Utilitária
Você não deve movê-los para uma class de utilitário, a menos que isso faça sentido em seu design. Se o método estático se relaciona a um tipo particular, como um ToRadians(double degrees) se relaciona a uma class que representa ângulos, faz sentido que o método exista como um membro estático desse tipo (note que este é um exemplo complicado para o fins de demonstração).

O desempenho, a poluição do espaço de nomes, 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 é o último, faça um método estático. Apenas mova-o para uma class de utilitário se estiver relacionado a um tipo que não esteja sob seu controle.

Às vezes, há methods que agem logicamente em uma instância, mas que ainda não usam nenhum estado da instância. Por exemplo, se você estivesse criando um sistema de arquivos e tivesse o conceito de um diretório, mas ainda não o tivesse implementado, poderia escrever uma propriedade retornando o tipo de object do sistema de arquivos, e sempre seria apenas “arquivo” – mas está logicamente relacionado à instância e, portanto, deve ser um método de instância. Isso também é importante se você quiser tornar o método virtual – sua implementação específica pode não precisar de estado, mas as classs derivadas podem. (Por exemplo, perguntar a uma coleção se é somente leitura ou não – você pode não ter implementado um formulário somente leitura dessa coleção ainda, mas é claramente uma propriedade da própria coleção, não do tipo.)

Marcar um método como static em uma class torna óbvio que ele não usa nenhum membro de instância que possa ser útil para saber quando estiver percorrendo o código. Você não precisa necessariamente movê-lo para outra class, a menos que seja destinado a ser compartilhado por outra class que seja tão intimamente associada, quanto ao conceito.

Tenho certeza de que isso não está acontecendo no seu caso, mas um “mau cheiro” que vi em algum código que tive que sofrer com a manutenção usou muitos methods estáticos.

Infelizmente, eles eram methods estáticos que assumiam um determinado estado de aplicativo. (por que, com certeza, teremos apenas um usuário por aplicativo! Por que a class User não tem controle sobre isso em variables ​​estáticas?) Eles eram formas glorificadas de acessar variables ​​globais. Eles também tinham construtores estáticos (!), Que são quase sempre uma má ideia. (Eu sei que há algumas exceções razoáveis).

No entanto, os methods estáticos são bastante úteis quando fatoram a lógica de domínio que não depende realmente do estado de uma instância do object. Eles podem tornar seu código muito mais legível.

Apenas certifique-se de colocá-los no lugar certo. Os methods estáticos manipulam intrusivamente o estado interno de outros objects? Pode ser feito um bom argumento de que o comportamento deles pertence a uma dessas classs? Se você não está separando as preocupações corretamente, você pode sentir dores de cabeça mais tarde.

Isto é interessante ler:

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

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 class em oposição a, digamos, uma das classs que aparece em sua assinatura …

mas aqui está o que resharper documentaion diz: http://confluence.jetbrains.net/display/ReSharper/Member+can+be+made+static

Apenas para adicionar à resposta do @Jason True, é importante perceber que apenas colocar ‘static’ em um método não garante que o método seja ‘puro’. Ele será sem estado em relação à class na qual ele é declarado, mas pode acessar outros objects ‘estáticos’ que têm estado (configuração de aplicativo etc.), isso pode nem sempre ser uma coisa ruim, mas uma das razões que Eu pessoalmente tendem a preferir methods estáticos quando posso, ou seja, se eles são puros, você pode testar e raciocinar sobre eles isoladamente, sem ter que se preocupar com o estado circundante.

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 realmente está acontecendo é que um parâmetro extra ( this ) está sendo empurrado para a pilha por methods de instância.

Para lógica complexa dentro de uma class, descobri que methods estáticos privados são úteis na criação de lógica isolada, na qual as inputs de 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 via valor de retorno ou parâmetros out / ref. Quebrar a lógica complexa em blocos de código sem efeitos secundários pode melhorar a legibilidade do código e a confiança da equipe de desenvolvimento nele.

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

ReSharper não verifica a lógica. Apenas verifica se o método usa membros da instância. Se o método é privado e só é chamado por methods de instância (talvez apenas um), isso é um sinal para permitir que ele seja um método de instância.

Se as funções forem compartilhadas em várias páginas, você também poderá colocá-las em uma class de página de base e todas as páginas asp.net usando essa funcionalidade herdarão dela (e as funções também poderão ser estáticas).

Tornar um método estático significa que você pode chamar o método de fora da class sem primeiro criar uma instância dessa class. Isso é útil ao trabalhar com objects de fornecedores ou complementos de terceiros. Imagine se você tivesse que primeiro criar um object de console “con” antes de chamar con.Writeline ();

Isso ajuda a controlar a poluição do namespace.

Apenas meu tuppence: Adicionando todos os methods estáticos compartilhados a uma class de utilitário permite que você adicione

 using static className; 

às suas instruções de uso, o que torna o código mais rápido de digitar e mais fácil de ler. Por exemplo, eu tenho um grande número do que seria chamado de “variables ​​globais” em algum código que eu herdei. Em vez de criar variables ​​globais em uma class que era uma class de instância, defini-as como propriedades estáticas de uma class global. Ele faz o trabalho, se messily, e eu posso apenas referenciar as propriedades pelo nome porque eu tenho o namespace estático já referenciado.

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

Joey