CodeRush предлагает сделать метод статичным, если у него есть параметры, согласны или не согласны?

Question

Я использую продукт CodeRush от Developer Express, который имеет функцию под названием Code Issues, которая предлагает рекомендации по оптимизации вашего кода. Я заметил, что если у вас есть метод с параметрами, он всегда предлагает сделать этот метод статичным. В духе попыток написать лучший и оптимизированный код, который, как я полагаю, и есть то, что DevExpress пытается нам помочь, я слышал неоднозначные мнения о том, действительно ли целесообразно делать метод статичным.

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

Хорошо или плохо?

Спасибо.

Answer 1

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

Например

 private static int Add(int a, int b) 
 { return a + b; }

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

Но в следующем классе PrintHello() не может быть объявлен как статический, посколькуон обращается к основанному на экземпляре полю useCount, даже если у него нет параметров.

public class myClass
{
    private int useCount = 0;

    private void PrintHello()
    { 
        useCount = useCount + 1;
        Console.Write("Hello");
    }
}

Answer 2

Как указали другие, наличие параметров не учитывается. Подсказка присутствует, когда метод не обращается ни к каким элементам экземпляра.

Когда это полезно?

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

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

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

Исключение этого типа экземпляра сэкономит процессор и память.

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

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

Например, класс System.Math является статическим и поэтому заполнен статическими функциями. Вызов кода для этих функций был бы менее читабельным, если бы ему пришлось создавать экземпляр класса math до выполнения.

Answer 3

Я обычно не использую статические методы, потому что их может быть сложно использовать с модульным тестированием и внедрением зависимостей. (Я знаю про typemock). Только если метод будет жестко ограничен, я рассмотрю использование статического метода.

Answer 4

Лично у меня два мнения на эту тему.

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

1. Загрязнение пространства имен.Если мы привыкнем к этой привычке, она начинает чахнуть на «старые добрые времена», когда все было сосредоточено на глобальных модулях, и вы могли бы просто вызывать функции невольно.Я содрогаюсь от этой мысли.Хотя статические методы , по общему признанию, организованы в классы и пространства имен, они по-прежнему не привязаны к конкретным экземплярам, ​​и мне просто попахивают глобальными функциями.Они заставляют мои пальцы изгибаться, как звуки ногтей на доске.

2. Тот факт, что метод не обращается к переменным экземпляра сегодня, не означает, что он не будет завтра.И рефакторинг для этого является критическим изменением. Создание статического метода - это не решение, которое следует принимать легко.Вы делаете это потому, что ЗНАЕТЕ, что метод предназначен для такого использования, а не потому, что инструмент заметил, что сегодня вы не используете переменные экземпляра.

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

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

В конечном итоге проблема производительности сводится к реализации.

Answer 5

Я бы лично сделал их статичными. Правильнее считать, что если что-то не работает в экземпляре, оно не должно быть членом в экземпляре (но в классе).

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

Я не думаю, что есть какое-то преимущество с точки зрения эффективности (хотя я не рассматривал это близко), просто в удобочитаемости кода.