Когда использовать статические классы в C#

Для C# 3.0 методы расширения могут существовать только в статических классах верхнего уровня.

Я использую только статические классы для вспомогательных методов, но с появлением C# 3.0 я бы предпочел использовать для них методы расширения.

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

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

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

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

public static class Log
{
   private static readonly ILoggerFactory _loggerFactory =
      IoC.Resolve<ILoggerFactory>();

   public static ILogger For<T>(T instance)
   {
      return For(typeof(T));
   }

   public static ILogger For(Type type)
   {
      return _loggerFactory.GetLoggerFor(type);
   }
}

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

Если вы используете инструменты анализа кода (например, FxCop), он порекомендует вам пометить метод static, если этот метод не имеет доступа к данным экземпляра. Причина в том, что есть прирост производительности. MSDN: CA1822 - пометить элементы как статические.

На самом деле это скорее рекомендация, чем правило ...

Я начал использовать статические классы, когда хочу использовать функции, а не классы, в качестве единицы повторного использования. Раньше я говорил о зле статических классов. Однако изучение F# заставило меня увидеть их в новом свете.

Что я имею в виду? Ну, скажем, работая над каким-то суперкодом СУХОЙ, я получаю кучу классов с одним методом. Я могу просто вывести эти методы в статический класс, а затем внедрить их в зависимости с помощью делегата. Это также хорошо работает с моим контейнером внедрение зависимости (DI) выбора Autofac.

Конечно, прямая зависимость от статического метода по-прежнему является злом как правило (есть некоторые не злые применения).

Решая, делать ли класс статическим или нестатическим, вам нужно посмотреть, какую информацию вы пытаетесь представить. Это влечет за собой более «вверх дном» стиль программирования, когда вы сосредотачиваетесь на данных, которые представляете в первую очередь. Является ли класс, в котором вы пишете, предмет из реального мира, например камень или стул? Эти вещи являются физическими и имеют физические атрибуты, такие как цвет, вес, которые говорят вам, что вы можете создать несколько объектов с разными свойствами. Мне может понадобиться черный стул И красный стул одновременно. Если вам когда-либо понадобятся две конфигурации одновременно, вы сразу узнаете, что хотите создать его экземпляр как объект, чтобы каждый объект мог быть уникальным и существовать одновременно.

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

Большинство классов могут быть представлены статическими или нестатическими, но если вы сомневаетесь, просто вернитесь к своим корням ООП и попытайтесь подумать о том, что вы представляете. Это объект, выполняющий действие (автомобиль, который может ускоряться, замедляться, поворачивать) или что-то более абстрактное (например, отображение вывода).

Свяжитесь со своим внутренним ООП, и вы никогда не ошибетесь!

Статические классы очень полезны и имеют место, например библиотеки.

Лучшим примером, который я могу предоставить, является класс .Net Math, статический класс пространства имен System, который содержит библиотеку математических функций.

Это похоже на все остальное: используйте правильный инструмент для работы, и если ничем нельзя злоупотреблять.

Бессмысленно отвергать статические классы как неправильные, не использовать их или говорить «может быть только один» или ни одного - так же неправильно, как и использовать их.

C# .Net содержит ряд статических классов, которые используются так же, как класс Math.

Так что при правильной реализации они чрезвычайно полезны.

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

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

Я просто добавлю к этому свои 2 цента, сказав, что я делаю класс статическим, когда этот класс является чем-то уникальным в системе и что действительно не имеет смысла иметь какие-либо его экземпляры в программе. Однако я оставляю это использование для больших классов. Я никогда не объявляю такие маленькие классы, как в примере MSDN, «статическими» и, конечно же, не классами, которые будут членами других классов.

Я также хотел бы отметить, что статический методы и статический классы - это две разные вещи, которые следует учитывать. Основные недостатки, упомянутые в принятом ответе, относятся к статическому методы. static классы предлагает ту же гибкость, что и обычные классы (когда речь идет о свойствах и параметрах), и все используемые в них методы должны соответствовать цели существования класса.

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

На основе MSDN:

1. Вы не можете создать экземпляр для статических классов
2. Если класс объявлен как статический, переменная-член должна быть статической для этого класса.
3. Запечатанный [не может быть унаследован]
4. Не может содержать конструктор экземпляра
5. Управление памятью

Пример: математические вычисления (математические значения) не меняются [СТАНДАРТНЫЙ РАСЧЕТ ДЛЯ ОПРЕДЕЛЕННЫХ ЗНАЧЕНИЙ]