Не использовать «статический» в C #?

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

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

Далее он упомянул кое-что, касающееся насмешек, методов IOC / DI, которые нельзя использовать со статическим кодом. Он говорит, что неудачно, когда сторонние библиотеки статичны из-за их непроверяемости.

Этот другой архитектор прав?

обновление: вот пример:

APIManager - этот класс содержит словари сторонних API, к которым я обращаюсь, в следующий раз. Он устанавливает ограничения на использование API, которые многие сторонние поставщики используют в своих условиях обслуживания. Я использую его везде, где я вызываю стороннюю службу, вызывая Thread.Sleep (APIManager.GetWait ("ProviderXYZ")); прежде чем сделать звонок. Все здесь является поточно-ориентированным и прекрасно работает с TPL в C #.

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

Он слишком общий по этому поводу. Он прав, это мешает тестированию. Однако staticклассы и методы имеют свое место, и это действительно зависит от контекста. Без примеров кода вы не можете сказать.

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

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

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

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

Лучшее, что можно сделать, это попробовать и юнит-тестировать свой код. Попробуйте разрабатывать повторяемые, независимые, простые тесты и тестировать только один метод за раз. Попробуйте запустить свои тесты в другом рандомизированном порядке. Можете ли вы получить стабильную «зеленую» сборку?

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

Уже опубликованные ответы охватывают много действительно хороших моментов, но есть один, который, кажется, отсутствует:

Статические поля никогда не собираются мусором.

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

Статические функции не так плохи, но все остальные уже достаточно подробно рассмотрели это.

Одним из преимуществ, которые вы получаете от IoC / DI, является то, что большинство взаимодействий между классами согласовываются между интерфейсами. Это облегчает модульное тестирование, потому что интерфейсы могут быть смоделированы автоматически или полуавтоматически, и, следовательно, каждая из частей может быть проверена на входы и выходы. Кроме того, помимо тестов, размещение интерфейсов между всем позволяет получить максимально модульный код - вы можете легко заменить одну реализацию, не беспокоясь о том, что вы облажаете зависимости.

Поскольку в C # нет метаклассов, класс не может реализовать интерфейс с использованием статических функций, поэтому статические функции классов заканчивают усилия по реализации чистой объектной модели IoC / DI. То есть вы не можете создать макет для их проверки, и вам нужно создать реальные зависимости.

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

Commenter напоминает мне о методах расширения, которые, конечно, должны быть в статических классах в C #. Это законно и является примером того, как чистый IoC не очень хорошо работает в C #, по крайней мере, если вы пытаетесь воспользоваться широтой языка.

Статические классы иногда используются неправильно и должны быть:

• singleton (где нестатический класс имеет статический член и общедоступную статическую переменную Instance для извлечения / создания его только один раз.
• метод в другом классе (где государство имеет значение). Если у вас есть член, который не использует данные из этого класса, вероятно, он не должен быть частью этого класса.

Это также может быть так называемая «служебная» функция и часть служебного класса. Служебные классы - это классы, которые содержат только статические методы и служат вспомогательными функциями без какого-либо контекста.

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

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

Пример PHP:

class vendorData {
  private static $data_table = 'vendor_data'; // static property
  private $id; // instance property
  private $name; // instance property

  public function __construct($vendor_id) {
    if(!self::validId($vendor_id) ) { // static method
      return false; // id doesn't exist
    }
    $this->id = $vendor_id; // id has been validated
    $this->getProperties(); // object method
  }

  private static function validId($vendor_id) {
    // send db query to find if the id exists
    // return true/false;
  }

  private function getProperties() { // object method
    $sql = "SELECT * FROM `{self::$data_table}` // using static property
        WHERE `id` = {$this->id}"; // using object instance property
    // get resultset
    foreach($result as $property => $value) {
      $this->$property = $value; // object instance properties all set
    }
  }

  // and here
  public static function getBy($property,$value) { // static method to return object array
    $sql = "SELECT `id` FROM `{self::$data_table}` // using static property
      WHERE `$property` = '$value'";
    // send query, get $ids array
    $obj_array = array();
    foreach($ids as $id) {
      // create array of current class objects using special static keyword
      // meaning of static here is different than in property/method declarations
      $obj_array[$id] = new static($id);
    }
    return $obj_array;
  }
}

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

Классы со статическими методами злоупотребляют принципами ООП. Это уже не ООП, это COP - классно-ориентированное программирование.

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

Следующий является следствием первого пункта. Так как такие классы не знают, кто они, они имеют тенденцию быть от большого до огромного.

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

Медленно, но неизбежно, ваш код становится все менее и менее связным, поскольку скрытые зависимости плохо контролируются. Они кажутся невидимыми. И это так легко добавить еще один! Вам не нужно изменять подпись любого метода. Все, что вам нужно сделать, это вызвать статический метод. И какой ужасный код следует ...

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

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