Анти-шаблон, который я наблюдал в некоторых проектах .NET, хотя он может быть одинаково актуален в любой объектно-ориентированной среде, заключается в размещении всех констант для проекта (или даже решения) в одном файле класса (например, Constants.cs).
При этом есть две основные проблемы:
1. Сплоченность
Константы очень часто не имеют между собой ничего общего (кроме того, что они константы). У некоторых разработчиков может возникнуть соблазн разместить вещи вместе только потому, что они одного типа (константа, перечисление, интерфейс и т. д.). Такого мышления следует избегать, поскольку оно ведет к плохой сплоченности.
Кент Бек сказал это лучше всего…
«Вещи, которые меняются с одинаковой скоростью, принадлежат друг другу. Вещи, которые изменяются с разной скоростью, принадлежат друг другу». — Кент Бек
2. Инкапсуляция
Когда все константы в решении помещаются в один файл класса, константы должны быть определены как общедоступные, чтобы их можно было использовать. Тот факт, что что-то является константой, не означает, что оно автоматически должно быть общедоступным и доступным для всего остального.
Например, почему константа должна быть общедоступной, а затем быть доступной для всего кода в решении (и, возможно, даже вне решения), если на самом деле она используется только одним классом?
Чтобы помочь в инкапсуляции типов и членов (включая константы), следует использовать наименее доступное ключевое слово доступа. Разработчики не должны устанавливать общедоступный метод доступа к типу или члену просто по привычке.
Исправление «Постоянного класса Бога»
Решение проблемы «константного класса Бога», очевидно, является движением к большей сплоченности и лучшей инкапсуляции. Это означает размещение констант ближе к тому месту, где они используются, и использование максимально ограничивающего доступа. Как только все константы будут перемещены, сам «Класс констант Бога» можно удалить.
Использование «константного класса Бога» иногда может указывать на то, что вместо этого приложение должно использовать параметры конфигурации. Разработчик, возможно, думал, что им нужно поместить все константы в одно место для простоты обнаружения/доступа в случае, если значения должны измениться в будущем. Если есть реальная возможность достаточно часто изменять значения констант (без изменения кода и повторного развертывания приложения), то вместо этого константа должна быть параметром конфигурации.
