Являются ли глобальные статические классы и методы плохими?

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

Ответ 1

Глобальные данные плохие. Однако многие проблемы можно избежать, работая со статическими методами.

Я собираюсь занять позицию Rich Hickey на этом и объяснить это следующим образом:

Для построения наиболее надежных систем на С# используйте статические методы и классы, но не глобальные данные. Например, если вы передаете объект данных в статический метод и что статический метод не имеет доступа к каким-либо статическим данным, вы можете быть уверены, что с учетом этих входных данных вывод функции всегда будет одинаковым. Это позиция, занятая Erlang, Lisp, Clojure и любой другой язык функционального программирования.

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

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

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


Позвольте мне уточнить некоторые дополнительные проблемы с Global Data. Постоянные (или только для чтения) глобальные данные не так велики, как переменные (чтение/запись) глобальных данных. Поэтому, если имеет смысл иметь глобальный кеш данных, используйте глобальные данные! В какой-то мере каждое приложение, использующее базу данных, будет иметь это, поскольку мы могли бы сказать, что вся база данных SQL - это одна массивная глобальная переменная, которая хранит данные.

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

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

Ответ 2

static не обязательно означает глобальное. Классы и члены могут быть static private, поэтому применяются только к определенному классу. Тем не менее, наличие слишком большого количества элементов public static вместо использования соответствующих способов передачи данных (вызовы методов, обратные вызовы и т.д.) Обычно плохо проектируется.

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

В качестве дополнения к тому, что сказано иначе, переменные final static просто прекрасны; константы - это хорошо. Единственное исключение - когда/если вы должны просто переместить их в файл свойств, чтобы их было легче изменить.

Ответ 6

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

Нет таких проблем со статическими методами.

Это оставляет статические поля (переменные). Если вы объявили статическое поле public в классе, это действительно будет глобальная переменная, и это будет плохо.

Но создайте статическое поле private, и большинство проблем будет решено. Или лучше, они ограничены классом, который делает их разрешимыми.

Ответ 7

Статические методы используются для реализации traits в Scala. В С# методы расширения (статические) выполняют эту роль в часть. Это можно видеть, как утверждают сторонники DCI, как "форма более высокого порядка полиморфизма" .

Кроме того, статические методы могут использоваться для реализации функций. Это то, что F # использует для реализации модулей. (А также VB.NET.) Функции полезны для (неудивительно) функционального программирования. И иногда это просто то, что нужно моделировать (например, "функции" в классе Math). Снова С# приближается здесь.

Ответ 8

public class Foo
{
    private static int counter = 0;

    public static int getCounterValue()
    {
         return counter;
    }
    //...
    public Foo()
    {
        //other tasks
        counter++;
    }
}

В приведенном выше коде вы можете увидеть, сколько мы подсчитали объекты Foo. Это может быть полезно во многих случаях.

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

Ответ 9

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

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

Ответ 10

Не совсем. Статический фактически определяет, когда, где и как часто что-то создается, а не кто имеет к нему доступ.