Стоит ли избегать статических классов?

Question

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

Answer 1

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

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

Как вы говорите, распространение классов "Помощник" может привести к неприятностям (дизайн, ремонтопригодность, читаемость, обнаруживаемость, другие способности ...). Здесь нет аргументов. Но можете ли вы утверждать, что класс "Помощник" никогда не подходит? Я сомневаюсь в этом.

Действительно, ответственное использование статических классов может принести большую пользу вашему коду:

• Статический класс Enumerable предоставляет набор методов расширения, которые многие из нас полюбили. Это логический набор функциональности / бизнес-логики, который не связан ни с каким конкретным типом.
• Услуги, предоставляемые средой / контекстом: например, ведение журнала, настройка (иногда)
• Другие (о которых я сейчас не могу думать):

Так что нет, в общем, это неплохая практика. Просто используйте их с умом ...

Answer 2

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

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

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

Answer 3

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

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

Answer 4

Нет, это не совсем правильно.

Существует множество функций, которые не относятся к экземпляру объекта и не требуют состояния. Например, рассмотрим математические функции.

Почти во всех языках есть что-то вроде:

y = Math.round(x);

Таким образом, функция round является статической. Вы могли бы, если бы вы сошли с ума, утверждать что-то вроде (C #):

class RoundFunction<T> : GeneralMathFunction<T>
{
    public override T Operate (params object[] variables) {
        ..
    }
}

Но, ИМХО, тебе было бы немного странно это делать.

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

Answer 5

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

как думать оо

одиночки

статическая-метода-это смерть к контролируемости

Answer 6

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

public static class Logging
{
  public static UpdateAction(int id, object data)
  {
     SqlConnection connection = new SqlConnection("conn string from config file");
     // more logic here...
  }
}

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

Так что не избегайте статических классов, просто избегайте, чтобы эти статические классы сохраняли какое-то глобальное состояние.

Answer 7

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