Почему и когда я должен сделать класс «статическим»? Каково назначение ключевого слова static на классах?

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

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

Это означает, что, например, Mathкласс может быть объявлен как обычный (не статический), не влияя на то, как разработчики кодируют. Другими словами, создание статического или нормального класса является своего рода прозрачным для разработчиков.

Для пользователей становится понятным, как используется класс. Например, было бы глупо написать следующий код:

Math m = new Math();

C # не должен запрещать это, но так как он не имеет смысла, он также может сказать пользователю об этом. Некоторые люди (включая меня) придерживаются философии, согласно которой языки программирования (и API-интерфейсы…) должны быть настолько ограничивающими, насколько это возможно, чтобы их было трудно использовать неправильно: единственными допустимыми операциями являются те, которые имеют смысл и (мы надеемся) правильные.

StackOverflow имеет отличную дискуссию на эту тему . Для удобства я скопирую и вставлю его от имени его автора Марка С. Расмуссена :

Я написал свои мысли о статических классах в более ранней теме :

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

Полиморфизм

Скажем, у нас есть метод UtilityClass.SomeMethod, который радостно гудит. Внезапно нам нужно немного изменить функциональность. Большая часть функциональности одинакова, но, тем не менее, мы должны изменить пару частей. Если бы это не был статический метод, мы могли бы создать производный класс и изменить содержимое метода по мере необходимости. Поскольку это статический метод, мы не можем. Конечно, если нам просто нужно добавить функциональность либо до, либо после старого метода, мы можем создать новый класс и вызвать внутри него старый класс - но это просто брутто.

Интерфейс беды

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

тестирование

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

Фостерс сгустки

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

Параметр ползучести

Начнем с того, что этот маленький симпатичный и невинный статический метод может принимать один параметр. По мере роста функциональности добавляется пара новых параметров. Вскоре добавляются дополнительные параметры, которые являются необязательными, поэтому мы создаем перегрузки метода (или просто добавляем значения по умолчанию на языках, которые их поддерживают). Вскоре у нас есть метод, который принимает 10 параметров. Только первые три действительно необходимы, параметры 4-7 являются необязательными. Но если указан параметр 6, необходимо заполнить 7-9 ... Если бы мы создали класс с единственной целью сделать то, что сделал этот статический метод, мы могли бы решить эту проблему, приняв необходимые параметры в конструктор и позволяющий пользователю устанавливать необязательные значения через свойства или методы для одновременного задания нескольких взаимозависимых значений. Также,

Требовательные потребители для создания экземпляра классов без причины

Один из наиболее распространенных аргументов: зачем требовать, чтобы потребители нашего класса создавали экземпляр для вызова этого единственного метода, но впоследствии не использовали этот экземпляр? Создание экземпляра класса является очень дешевой операцией в большинстве языков, поэтому скорость не является проблемой. Добавление дополнительной строки кода для потребителя - это низкая стоимость, чтобы заложить основу гораздо более удобного в будущем решения. И, наконец, если вы хотите избежать создания экземпляров, просто создайте одноэлементную оболочку вашего класса, которая позволяет легко использовать повторно - хотя это делает требование, чтобы ваш класс не имел состояния. Если это не состояние, вы все равно можете создавать статические методы-обертки, которые обрабатывают все, но при этом дают вам все преимущества в долгосрочной перспективе. В заключение,

Только ситхи имеют дело с абсолютами

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

Стандарты, стандарты, стандарты!

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

Я удивлен, что никто не упомянул, что staticклассы допускают методы расширения - безопасное расширение существующего типа (включая добавление определений методов к интерфейсам ), которым вы не владеете. Например, что в Scala

trait MyFoo {
  def foo: Int
  def plusFoo(a: Int) = foo + a
}

может быть выражено в C # как

public interface IMyFoo {
  int Foo();
}

public static class MyFooExtensions {
  public static int PlusFoo(this IMyFoo f, int a) {
    return f.Foo() + a;
  }
}

Для меня статический класс (в C #) подобен вызову функции.

Например

public static string DoSomething(string DoSomethingWithThisString){}

Я передаю строку и получаю обратно строку. Все содержится в этом методе. Нет доступа к переменной-члену и т. Д.

Честно говоря, в основном он использовался для уменьшения количества строк кода:

Почему:

MyClass class = new MyClass();
String s = class.DoSomething("test");

Когда я могу сделать это:

String s = MyClass.DoSomething("test");

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

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

Это может быть упрощенно, но в основном я так и использовал static.