Когда сделать метод статичным?

Я использую статические методы, когда могу. Преимущества:

• При вызове статического метода изнутри метода экземпляра вы можете быть уверены, что нет побочных эффектов на состояние текущего объекта.
• Изнутри статического метода вы можете быть уверены, что случайно не изменили какое-либо состояние экземпляра объекта.
• Вы можете использовать статический метод извне класса без создания экземпляра. Если бы можно было сделать метод статическим, ему явно не нужен экземпляр, поэтому в нем нет необходимости.
• Статические методы могут быть немного более эффективными, потому что не нужно передавать указатель this и не требуется динамическая отправка.

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

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

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

пс. Архимед правил!

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

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

« чистая функция » - это любой метод, который не изменяет какое-либо состояние и чей результат не зависит ни от чего, кроме предоставленных ему параметров . Так, например, , любая функция, которая выполняет ввод-вывод (прямо или косвенно), не является чистой функцией , а Math.sqrt () из {{1} } конечно, есть.

Я склонен согласиться. (Хотя в моем собственном коде я традиционно, вероятно, использовал слишком много статических вспомогательных методов повсюду ... :-P И это определенно сделало код, который использует эти методы, труднее для тестирования.)

(C#) По умолчанию я использую статические методы в статических классах и нестатические методы в нестатических классах.

По мере того, как я разрабатываю класс, я естественным образом прихожу к тому, чтобы сделать его полностью статическим или полностью нестатическим. Практически говоря, если я начинаю определять статические члены в нестатическом классе, я часто обнаруживаю, что в конечном итоге наиболее целесообразно выделить их в отдельный статический класс - либо в утилитарный класс, например Math, либо в класс глобального приложения (например, ConfigurationManager в .NET).

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

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

Прекрасным примером может служить метод sqrt класса Math .

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