Должен ли я всегда ставить свои методы статически, когда это возможно?

Question

Я часто размышлял над этим ... его, вероятно, вопрос идиот, но здесь идет.

Скажем, у меня есть этот класс:

public class SomeClass 
{ 
    public int AProperty { get; set; } 

    public void SomeMethod() 
    { 
     DoStuff(AProperty); 
    } 
} 

Есть ли какие-либо преимущества делают это:

public class SomeClass 
{ 
    public int AProperty { get; set; } 

    public static void SomeMethod(int arg) 
    { 
     DoStuff(arg); 
    } 
} 

Единственное преимущество, что очевидно является то, что теперь я могу получить доступ к SomeMethod непосредственно.

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

EDIT: Я забыл упомянуть (и комментарий SHELLSHOCK напомнил мне), что причина, я спрашиваю, что я использую ReSharper и это всегда делает предположение, что «Метод X можно сделать статическим» и так далее ...

Answer 1

Статик не злой. Static является злым, если используется неправильно, как и многие части нашего инструментария программирования.

Статический может быть очень выгодным. Как указывает the accepted answer here, статические могут иметь возможность улучшения скорости.

Как правило, если метод не используется и поля класса, то его хорошее время для оценки его функции, однако в конечном итоге полезные методы, которые могут быть вызваны без создания экземпляра объекта, могут быть полезны. Например, классы DirectoryInformation и FileInformation содержат полезные статические методы.

Редактировать

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

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

Answer 2

Номер Static is evil. Он плотно соединяет вызывающего абонента с используемым классом и makes it hard to test.

Answer 3

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

Для примера предположим, что у вас есть класс строк и две строки A и B. Для сравнения A и B вы можете использовать метод A.CompareTo (B) или String.Compare (A, B).

Пожалуйста, исправьте меня, если я ошибаюсь.

Answer 4

Статические методы имеют смысл, если вы сможете называть их, не создавая объект класса раньше. В Java, например, Math-Class содержит только статические методы, потому что не имеет смысла инициировать Math-Class только для выполнения математических операций над другими объектами.

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

Answer 5

Я попытаюсь ответить на ваш конкретный вопрос, связанный с примером кода, который вы предоставили.

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

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

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

Для (очень простой), например, когда статический является злом, но могут быть преобразованы в не злой версии, представьте себе функцию, которая вычисляет чей-то возраст:

static TimeSpan CalcAge(DateTime dob) { return DateTime.Now - dob; } 

Это проверяемым? Ответ - нет. Он опирается на массово изменчивое статическое состояние, которое составляет DateTime.Now. Вам не гарантируется одинаковый выход для одного и того же входа каждый раз. Для того, чтобы сделать его более дружественным тест:

static TimeSpan CalcAge(DateTime dob, DateTime now) { return now - dob; } 

Теперь все значения функции опирается на передаются в, и это полностью проверяемым. Тот же ввод даст вам тот же результат.