Мы создали собственный инструмент, который выполняет запросы, указанные в одном или нескольких файлах во время сборки, и генерирует классы перечислимых типов, по одному для каждой таблицы справочных данных. Как минимум, инструмент требует, чтобы справочные таблицы данных имели только два столбца: первичный ключ (с уникальными ограничениями) и строку. У каждого экземпляра enum есть имя, сгенерированное из строки (после того, как он был преобразован в алгоритм преобразования имени в верхний регистр, замены пробелов и других недопустимых символов в подчеркивания и т. Д.).
Инструмент достаточно гибкий, чтобы учесть дополнительные свойства для каждого значения; например, «отображаемое имя», «описание», могут быть связанные числовые значения и другие простые типы. Мы также генерируем статические методы в классе enum для получения различных подмножеств значений; всегда есть хотя бы одно, которое возвращает все значения, но у нас могут быть дополнительные значения, сгенерированные на основе запросов SQL. Например, для перечисления цветов у нас может быть статический метод «primaryColors ()». Дополнительные статические методы создаются для поиска значения на основе его ключа; например.,
public static Color valueOf(int key);
Перечисления позволяют легко и удобно читать общеизвестные ссылочные значения в коде; например.,
if (selectedColor == Colors.RED) {
.
.
.
}
Это имеет недостаток, заключающийся в необходимости дополнительного шага сборки, но в нашем случае это значительно перевешивает преимущества: более чистый код, гарантия того, что пользовательский интерфейс, бизнес-логика и допустимые значения базы данных синхронизированы и т. Д.
Мы часто говорили о том, чтобы иметь гибрид статического механизма, как описано выше, плюс добавление более динамичного поведения, но мы никогда не чувствовали его достаточно убедительным, чтобы добавить к сложности.