Работа с перечислениями в многозадачной среде - PullRequest
3 голосов
/ 28 октября 2011

Наша фирма разрабатывает в основном на Java и поддерживает ряд «живых» систем (в основном, долго выполняющихся серверных процессов), все они зависят от общих справочных данных и перечислений. Иногда определение enum расширяется, чтобы включить новое значение, и в этом случае мы в настоящее время переустанавливаем все наши приложения , когда это происходит, причина в том, что у каждого приложения есть отдельная папка "lib", содержащая все библиотеки jar (включая библиотека enum entity). Очевидно, что это нежелательно, и поэтому мне было бы интересно услышать рекомендации или подходы других людей.

Идеи, о которых я думал:

  1. Изменение сценария запуска каждого приложения для получения самой последней версии библиотеки "enum entity" и добавления файла jar к пути к классам.
  2. Какой-то механизм динамической классификации загрузки нового определения перечисления во время выполнения.

Проблема с этими подходами состоит в том, что приложения обычно имеют код в формате:

switch(enumVal) {
  case A:
    // Do something.
    break;
  case B:
    // Do something.
    break;
  default:
    throw new IllegalArgumentException("Invalid enum value: " + enumVal);
}

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

Ответы [ 2 ]

1 голос
/ 28 октября 2011

Объектная ориентация была придумана специально для решения этой проблемы: ваш переключатель на самом деле является просто явной виртуальной таблицей, когда неявная была бы намного лучше. Вам следует подумать о редизайне вашего приложения, чтобы использовать интерфейсы / базовые классы вместо перечислений.

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

Самый простой способ избежать перекомпиляции - это, вероятно, принять Dependency Injection . С такой платформой, как Spring , вы можете иметь один или несколько файлов конфигурации, в которых вы указываете объекты, которые необходимо создать, а затем можете загружать их по имени.

1 голос
/ 28 октября 2011

г.Смит прав: расширение enums или «перечислимых» int-констант старой школы в этом отношении вряд ли может быть сделано правильно и обычно не является хорошим подходом.
Как вы подразумеваете, новые значения перечисления требуют особого поведения /обработка клиентами, использующими их.Как только вы измените перечисление, вы, таким образом, должны также изменить клиентов.Это действительно плохо, и вы должны действительно попытаться изменить его по-другому.

...