Как ответить
Глобальное состояние — это данные, доступные из любой точки программы без явной передачи: глобальные переменные, синглтоны, статические поля, сервисы-одиночки. На практике оно создаёт скрытые связи между компонентами и превращает код в «клубок» — изменить одно место, не сломав другое, становится очень сложно.
Основные проблемы:
- Неявные зависимости. Функция использует глобальный объект — её контракт перестаёт быть прозрачным. Чтобы понять, какие данные ей нужны, приходится лезть в реализацию.
- Сложность тестирования. Глобальное состояние остаётся между тестами. На прошлом проекте я тратил часы на обнуление синглтонов в setUp — если пропустить, тесты начинали влиять друг на друга. Приходилось писать костыли вроде «сбросить перед каждым тестом», но это хрупко.
- Race conditions в многопоточности. Два потока пишут в один глобальный кэш — получаем гонку данных. Решение через блокировки усложняет код и снижает производительность.
- Нарушение инкапсуляции. Любой участок кода может изменить глобальное состояние, что ведёт к неожиданным эффектам (сложно отлаживать).
- Трудность рефакторинга. Глобальный синглтон тянется в десятки мест — заменить его на нормальную зависимость придётся «одним коммитом» с риском всё сломать.
Пример из практики: В микросервисе был глобальный реестр фич-флагов (статический словарь). Один модуль выключал флаг, не подозревая, что другой уже проверил его и закешировал решение. На production падали запросы. Мы перешли на внедрение зависимости — каждый сервис получает провайдер флагов через конструктор. Теперь явно видно, откуда берутся данные.
Когда глобальное состояние всё же оправдано? Только для действительно глобальных констант (например, версия приложения) или для монотонно наращиваемых счётчиков в строго контролируемой среде. В остальных случаях лучше использовать внедрение зависимостей (DI) или передачу состояния через аргументы функции.