ReSharper намекает, что я должен делать статические методы в WebForms - Почему? Я что-то пропустил? - PullRequest
1 голос
/ 05 января 2010

ReSharper иногда намекает на то, что некоторые из моих случайных служебных методов могут быть статическими в моих WebForms. Зачем мне это делать? Насколько я могу судить, в этом нет никакой пользы .. или есть? Я что-то упускаю из-за статических элементов в WebForms?

Ответы [ 4 ]

9 голосов
/ 05 января 2010

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

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

class C 
{
  public int DoubleIt(int x, string y, Type z)
  {
    return x * 2;
  }
}

Это хорошо разработанный метод? Нет. Требуется вся информация, которую он затем игнорирует и не использует для вычисления результата или выполнения побочного эффекта. Зачем заставлять абонента передавать ненужную строку и вводить?

Теперь обратите внимание, что этот метод также принимает C, в форме «this», переданного в вызов. Это также игнорируется. Этот метод должен быть статическим и принимать один параметр.

Хорошо разработанный метод принимает именно ту информацию, которая ему необходима для вычисления результатов и выполнения побочных эффектов, не больше и не меньше. Решарпер говорит вам, что у вас есть недостаток дизайна в вашем коде: у вас есть метод, который принимает информацию, которую он игнорирует. Либо исправьте метод, чтобы он начал использовать эту информацию, либо прекратите передачу бесполезных данных, сделав метод статичным.

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

5 голосов
/ 05 января 2010

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

Для меня это хороший совет, когда я читаю чужой код. Я не слишком беспокоюсь об общем состоянии и могу видеть поток информации более легко. Он гораздо более ограничен в том, что он может сделать, объявив его статическим, что меньше беспокоит меня, читателя.

4 голосов
/ 05 января 2010

Вы получите улучшение производительности, правило FxCop CA1822 такое же.

С MSDN :

Методы, которые не обращаются к экземпляру методы данных или экземпляра вызова могут быть помечен как статический (Общий в Visual Basic). После того, как вы отметите методы как статический, компилятор выдаст не виртуальные сайты вызова на эти члены. Излучение не виртуального вызова сайты будут препятствовать проверке во время выполнения для каждого вызова, который гарантирует, что текущий указатель объекта не нулевой. Это может привести к измеримым увеличение производительности для чувствительный к производительности код. В некоторых случаях, невозможность доступа к текущий экземпляр объекта представляет собой вопрос правильности

2 голосов
/ 05 января 2010

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

Преимуществом может быть незначительное увеличение производительности (приложение будет использовать меньше памяти), и будет еще одно предупреждение с меньшей резкостью;)

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