Метод может быть сделан статичным, но должен он?

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы добавить к ответу @Jason True , важно понимать, что простое добавление «статики» к методу не гарантирует, что метод будет «чистым». Он не будет иметь состояния по отношению к классу, в котором он объявлен, но может получить доступ к другим «статическим»

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

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