Следует ли избегать статических классов?
считаются ли статические классы плохой практикой? Я прочитал статью об этом пару дней назад (не могу найти его, извините), в которой в основном говорилось, что статические классы (особенно эти "вспомогательные" классы) обычно являются признаком плохого кода. Правильно ли это, и если да, то по каким причинам?
7 ответов
злоупотребление статическими классами можно считать плохой практикой. Но так же может быть и злоупотребление любой языковой особенностью.
Я не делаю различия между нестатическим классом только со статическими методами и статическим классом. Они фактически одинаковы, за исключением того, что статические классы позволяют компилятору применять намерение разработчиков (нет экземпляра этого класса, удобный синтаксис для доступа к его функциональности,etc).
Как вы говорите, распространение "Вспомогательные" классы могут доставить вам неприятности (дизайн, ремонтопригодность, читаемость, открываемость, другие-способности...). Никаких возражений. Но можете ли вы утверждать, что "помощником" класс никогда уместно? Сомневаюсь.
действительно, ответственное использование статических классов может иметь большие преимущества для вашего кода:
- на
Enumerable
статический класс предоставляет набор методов расширения, которые большинство из нас полюбили. Они представляют собой логический набор функциональности / бизнеса логика, которая не связана с экземпляром какого-либо конкретного типа. - услуги, предоставляемые средой / контекстом: например, ведение журнала, конфигурация (иногда)
- другие (о которых я сейчас не могу думать:))
Так что нет, в целом это неплохая практика. Просто используйте их с умом...
означает ли это, что "использование статических классов неправильно" (в этом случае статья неверна) или "статические классы часто встречаются в плохо написанном коде" (в этом случае это не говорит о том, что статические классы сами по себе плохи, но что они иногда используются неправильно)
статические функции более эффективны, чем нестатические, потому что вам не нужно создавать экземпляр объекта для их использования или передавать указатель "this" в вызовы методов.
использование статических классов держать глобальные переменные-это другое дело , и в этом случае основное правило заключается не в том, что "статика плоха", а в том, что "глобалы плохи".
Я думаю, что общий аргумент против сохранения изменяемого состояния в статических классах и в основном использует их в качестве глобальных переменных. Нет ничего плохого в статических вспомогательных методах в статическом классе.
а что касается того, почему глобальные переменные плохие, я уверен, что между здесь и google вы найдете полмиллиона страниц и сообщений в блоге об этом.
нет, это не совсем правильно.
существует множество функций, которые не являются специфичными для экземпляра объекта и не требуют состояния. Например, рассмотрим "математические" функции.
почти все языки имеют что-то вроде:
y = Math.round(x);
таким образом, функция "круглый" является статической. Вы могли бы, если бы Вы были сумасшедшими, спорить о чем-то вроде (C#):
class RoundFunction<T> : GeneralMathFunction<T>
{
public override T Operate (params object[] variables) {
..
}
}
но, ИМХО, тебе было бы немного странно это делать.
конечно есть время, когда слишком много статических функций являются признаком того, что что-то пошло не так, но, в разумных пределах, это не "плохо".
вот некоторые ссылки на некоторые сообщения Google testing blog о том, почему статические методы могут повредить тестируемости вашего кода, а также почему статические методы (которые являются плохой частью статических классов) вводят все виды потенциально удивительной связи и взаимодействия между компонентами.
есть потребности, где у вас есть класс утилиты, где все методы статичны. В этом случае, если вы сделаете класс статичным, это ясно указывает на ваше намерение. И, по крайней мере, в C# вы не можете иметь нестатических методов внутри статического класса.
Я использую статические служебные классы все время в моем коде для методов, которые вызываются довольно часто, но было бы больно создавать экземпляры. Примером может быть простой класс ведения журнала, например:
public static class Logging
{
public static UpdateAction(int id, object data)
{
SqlConnection connection = new SqlConnection("conn string from config file");
// more logic here...
}
}
теперь, никоим образом, у меня никогда не было этих классов и методов, хранящих какое-либо глобальное состояние, так как это может привести к огромным проблемам совпадения и в целом просто плохой дизайн.
поэтому не избегайте статических классов, просто избегайте того, чтобы эти статические классы сохраняли какой-то глобальный государство.