Метод можно сделать статическим, но нужно ли это делать?

Question

Resharper любит указывать на несколько функций на странице asp.net, которые можно сделать статическими.Поможет ли мне, если я сделаю их статичными?Должен ли я сделать их статическими и переместить в служебный класс?

Answer 1

Статические методы и методы экземпляра
10.2.5 Статические и экземпляры-члены C # Спецификация языка объясняет разницу. Как правило, статические методы могут обеспечить очень небольшое повышение производительности по сравнению с методами экземпляра, но только в несколько экстремальных ситуациях (см. этот ответ для некоторые подробности об этом).

Правило CA1822 в состояниях FxCop или Code Analysis:

  

" После [пометка элементов как статических] компилятор отправляет не виртуальные сайты вызовов этим участникам, что предотвращает проверку при   время выполнения для каждого вызова, который гарантирует, что текущий указатель объекта   ненулевой. Это может привести к ощутимому приросту производительности для   чувствительный к производительности код. В некоторых случаях невозможность доступа к   текущий экземпляр объекта представляет проблему правильности. "

Класс утилит
Вы не должны перемещать их в служебный класс, если это не имеет смысла в вашем дизайне. Если статический метод относится к определенному типу, как метод ToRadians (double степени) относится к классу, представляющему углы, то имеет смысл, чтобы этот метод существовал как статический член этого типа (примечание, это запутанный пример для демонстрации).

Answer 2

На мой взгляд, производительность, загрязнение пространства имен и т.д. Спросите себя, что логично. Является ли метод логически работающим с экземпляром типа или он связан с самим типом? Если это последнее, сделайте это статическим методом. Перемещайте его в служебный класс только в том случае, если он относится к типу, который не находится под вашим контролем.

Иногда существуют методы, которые логически действуют на экземпляр, но не используют ни одно из состояний экземпляра пока . Например, если вы строите файловую систему и у вас есть понятие каталога, но вы еще не реализовали его, вы можете написать свойство, возвращающее тип объекта файловой системы, и оно всегда будет просто & Quot; файл & Quot; - но он логически связан с экземпляром, и поэтому должен быть методом экземпляра. Это также важно, если вы хотите сделать метод виртуальным - вашей конкретной реализации может не потребоваться состояние, но могут производные классы. (Например, спрашивая коллекцию, доступна ли она только для чтения - возможно, вы еще не внедрили форму этой коллекции только для чтения, но это явно свойство самой коллекции, а не ее типа.)

Answer 3

Маркировка метода как static в классе делает очевидным, что он не использует никаких элементов экземпляра, что может быть полезно знать при просмотре кода.

Вам не обязательно перемещать его в другой класс, если он не предназначен для совместного использования другим классом, который также тесно связан концептуально.

Answer 4

Я уверен, что в вашем случае этого не происходит, но один "неприятный запах" Я видел в каком-то коде, от которого мне пришлось страдать, используя множество статических методов.

К сожалению, это были статические методы, которые принимали определенное состояние приложения. (почему, конечно, у нас будет только один пользователь на приложение! Почему бы классу User не отслеживать это в статических переменных?) Они были прославленными способами доступа к глобальным переменным. У них также были статические конструкторы (!), Что почти всегда было плохой идеей. (Я знаю, что есть несколько разумных исключений).

Однако статические методы весьма полезны, когда они исключают предметную логику, которая на самом деле не зависит от состояния экземпляра объекта. Они могут сделать ваш код более читабельным.

Просто убедитесь, что вы помещаете их в нужное место. Являются ли статические методы навязчиво манипулирующими внутренним состоянием других объектов? Можно ли доказать, что их поведение относится к одному из этих классов? Если вы не разделяете проблемы должным образом, у вас могут возникнуть головные боли позже.

Answer 5

Это интересно читать:

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

ReSharper не предлагает фактически сделать ваш метод статичным. Вы должны спросить себя, почему этот метод находится в этом классе, а не, скажем, в одном из классов, который отображается в его подписи ...

Но вот что говорит более резкая документация: http://confluence.jetbrains.net/display/ReSharper/Member + может + быть + сделано + статические

Answer 6

Просто для добавления в @Jason True's ответ , важно понимать, что просто добавление «static» к методу не гарантирует, что метод будет «чистым». Он не будет иметь состояния в отношении класса, в котором он объявлен, но он вполне может обращаться к другим «статическим» объектам, которые имеют состояние (конфигурация приложения и т. Д.), Это не всегда плохо, но одна из причин того, что Лично я склонен отдавать предпочтение статическим методам, когда могу, если они чистые, вы можете проверять и рассуждать о них изолированно, не беспокоясь об окружающем состоянии.

Answer 7

Вы должны делать то, что наиболее читабельно и интуитивно понятно в данном сценарии.

Аргумент производительности не является хорошим, за исключением самых экстремальных ситуаций, поскольку единственное, что на самом деле происходит, - это то, что один дополнительный параметр ( this ) помещается в стек для методов экземпляра.

Answer 8

Для сложной логики в классе я обнаружил, что частные статические методы полезны при создании изолированной логики, в которой входные данные экземпляров четко определены в сигнатуре метода, и побочные эффекты экземпляров не могут возникнуть. Все выходы должны быть через возвращаемое значение или параметры out / ref. Разбиение сложной логики на блоки кода без побочных эффектов может улучшить читабельность кода и доверие команды разработчиков к нему.

С другой стороны, это может привести к классу, загрязненному распространением служебных методов. Как обычно, логическое именование, документирование и последовательное применение правил коллективного кодирования могут облегчить это.

Answer 9

ReSharper не проверяет логику. Он только проверяет, использует ли метод элементы экземпляра. Если метод является закрытым и вызывается только (возможно, одним) методами экземпляра, это признак того, что он может быть методом экземпляра.

Answer 10

Если функции используются на многих страницах, вы также можете поместить их в класс базовой страницы, а затем наследовать от него все страницы asp.net, использующие эту функциональность (при этом функции также могут быть статическими).

Answer 11

Создание статического метода означает, что вы можете вызывать метод извне класса без предварительного создания экземпляра этого класса. Это полезно при работе с объектами сторонних поставщиков или надстройками. Представьте себе, если вам нужно было сначала создать консольный объект " con " перед вызовом con.Writeline ();

Answer 12

Это помогает контролировать загрязнение пространства имен.

Answer 13

Просто мой таппенс:Добавление всех общих статических методов в служебный класс позволяет вам добавить

using static className; 

к вашим операторам использования, что ускоряет ввод кода и облегчает его чтение.Например, в каком-то коде, который я унаследовал, у меня есть большое количество того, что можно было бы назвать «глобальными переменными».Вместо того, чтобы создавать глобальные переменные в классе, который был экземплярным классом, я установил их все как статические свойства глобального класса.Он выполняет свою работу, хотя и беспорядочно, и я могу просто ссылаться на свойства по имени, потому что у меня уже есть ссылка на статическое пространство имен.

Я понятия не имею, хорошая это практика или нет.Мне нужно так много узнать о C# 4/5 и так много устаревшего кода, который нужно реорганизовать, что я просто пытаюсь следовать советам Розелин.

Джоуи