Выбор между enum и final class для хранения опций

Разрабатываю приложение на Java 8, в котором мне необходимо использовать некие настройки. Настройки могут быть разными, объединяет их сейчас то, что есть некоторое представление настройки (сейчас это - элемент перечисления), и ключ и значение настройки. Настройки планируется добавлять в ArrayList
Сейчас передо мной встал выбор - использовать ли перечисление, реализующее общий интерфейс, для хранения настроек, или же попробовать воспользоваться final class
Конкретно Java я только начинаю всерьёз заниматься, поэтому вопрос может быть глуповат, но поиск в Сети на русском и английском языках не дал мне ясности.
Привожу пример (абстрактный), как реализовано сейчас:
public interface Option { public String getKey(); public String getValue(); }
public enum Option1 implements Option { OPTION1_VALUE_1("one"), OPTION1_VALUE_2("two"); private final String key; private final String value; Option1(String val) { this.key = "key1"; this.value = val; } @Override public String getKey() { return this.key; } @Override public String getValue() { return this.value; } }
public enum Option2 implements Option { OPTION2_VALUE_1("aaa"), OPTION2_VALUE_2("bbb"); private final String key; private final String value; Option2(String val) { this.key = "key2"; this.value = val; } @Override public String getKey() { return this.key; } @Override public String getValue() { return this.value; } }
Затем я планирую использовать эти "опции" как-то так:
List options = new ArrayList; options.add(Option1.OPTION1_VALUE_1); options.add(Option2.OPTION2_VALUE_1); options.add(Option2.OPTION2_VALUE_2); // А теперь, например, обходим список и выводим value for (Option opt : options) { System.out.println(opt.getValue()); }
Вот, собственно, для этих целей я и использую интерфейс.
В данной реализации мне (а как показал поиск - и многим другим вопрошающим) не нравится необходимость в каждом enum'е переопределять функции getKey() и getValue(). Наследовать enum от класса Java не позволяет.
Гугление привело меня к статье "Constant interface" в Википедии, откуда я почерпнул идею реализовать подобное поведение через final class
Реализацию я вижу примерно так:
public class Option { protected final String key; public getKey() { return this.key; } }
public final class Option1 extends Option { Option() { this.key = "key1"; } public static final String OPTION1_VALUE_1 = "one"; public static final String OPTION1_VALUE_2 = "two"; }
public final class Option2 extends Option { Option() { this.key = "key2"; } public static final String OPTION2_VALUE_1 = "aaa"; public static final String OPTION2_VALUE_2 = "bbb"; }
Код накидывал прямо здесь, без отладки, лишь чтобы передать идею. Соответственно, при такой реализации я отказываюсь от метода getValue() и получаю значение через сам член класса.
Собственно, вопросы:
Можно ли всё-таки как-то избежать необходимости переопределения getKey() и getValue() в первом варианте реализации (через enum'ы)? Насколько вообще адекватна первая реализация, с позиции более опытных разработчиков? Жизнеспособна ли идея второй реализации (через final class)? Лучше ли она, чем использование enum'ов? Лично мне кажется для этих целей более правильно использовать перечисление, но из-за недостатка опыта я сильно сомневаюсь в таком решении.

Ответ

Первую реализацию можно заменить на более удачную. В Enum можно определять свои конструкторы и методы. Тогда нет необходимости создавать интерфейс и т.п.. Мне кажется это будет наиболее удачным вариантом решения.
public enum Option { OPTION_1("key 1", "value 1"), OPTION_2("key 2", "value 2");
private String key; private String value;
Option(String key, String value) { this.key = key; this.value = value; }
public String getKey() { return key; }
public String getValue() { return value; } }
UPDATE
По поводу использования. Если необходимо пройтись по всем опциям, то есть стандартный метод values()
for (Option op : Option.values()) { System.out.println(op.getKey() + " - " + op.getValue()); }
Если необходимо оперировать только частью опций, то используйте EnumSet, который предоставляет компактную и быструю структуру данных за счет внутренней реализации в виде битового вектора.