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

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

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

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

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

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

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

Это скорее правило, чем правило, действительно...

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

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 вызывается со статическим аксессуаром. В большинстве случаев для меня, если вы можете вызвать статические методы в классе, все, что вы можете сделать, я помечаю класс как статический для большей ясности.

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

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

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

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

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

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

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

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

Поэтому, учитывая правильную реализацию, они чрезвычайно полезны.

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

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

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

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

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

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

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

На основе MSDN:

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

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

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

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