Java: `enum` против` String` как параметры
Я читал подробную информацию о методах System и set библиотек get, но параметрами обычно являются строки.
Считаете ли вы использование String в качестве параметров плохой практикой с момента включения enum?
Лучшей альтернативой, как минимум, может быть public final String, нет?
Ответы 7
Я бы посчитал Enums лучшим подходом, чем Strings. Они безопасны по типу, и их сравнение выполняется быстрее, чем сравнение строк.
В качестве альтернативы до Java 1.5 вы можете использовать шаблон перечисления, безопасный для типов, предложенный Джошуа Блохом в его книге «Эффективная Java». Для типобезопасных перечислений см. Также http://www.javacamp.org/designPattern/enum.html
Я изучил «метод наименьшего удивления». Инстинктивно использование enum - правильное решение. Так что я бы пошел на это. Я уверен, что создатели Java думают одинаково.
Редактировать: Отличное объяснение POLS: http://benpryor.com/blog/2006/06/29/api-design-the-principle-of-least-surprise/
Просто потому, что вы объявляете public final String как нечто, что вы ожидаете передать в метод в качестве параметра, ничто не мешает мне передать все, что мне нравится.
Использование enum означает, что я не могу создать свой собственный объект для передачи, защищая обе стороны проблемы. Единственный раз, когда я могу подумать, что вам следует использовать постоянные строки вместо перечислений, - это если вам нужно предоставить пользователю место для расширения вашего метода, чтобы включить настраиваемые функции ...
Если вы имеете в виду System.setProperty (), System.getProperty () или System.getenv (), я думаю, что здесь подходят строки, поскольку набор возможных ключей открыт. Параметр ключа соответствует фактическому значению типа текст / строка в каком-либо файле или хранилище.
Если у вас есть закрытый набор ключей, я думаю, что перечисления будут намного предпочтительнее.
Я думал об этом, что перечисление может иметь детали сопоставления для параметров, не зависящих от платформы, что оба должны использоваться, а не только строки, и что строковые методы должны быть устаревшими, чтобы стимулировать принятие перечислений.
Я думаю, что различие между «закрытыми» наборами клавиш и «открытыми» наборами клавиш является здесь наиболее важным фактором. Если вы посмотрите на API с динамически загружаемыми подключаемыми модулями, они могут предоставлять дополнительные функции, к которым можно получить доступ через параметр String, но с перечислением будет сложнее.
Использование строк в существующих API - неплохая практика; это плохая практика - менять API только потому, что Java теперь поддерживает перечисления. Что касается новых API, я согласен с тем, что сказали все.
Перегрузка? Копия моего комментария к lycono: «Я думал об этом, что перечисление может иметь детали сопоставления для параметров, не зависящих от платформы, что оба должны использоваться, а не только строки, и что строковые методы должны быть устаревшими, чтобы стимулировать принятие перечислений»
Если ваш набор параметров ограничен и известен во время компиляции, используйте enum.
Если ваш набор параметров открыт и неизвестен во время компиляции, используйте строки.
Хотя использование перечислений является типобезопасным, необходимость преобразования перечисления в строку и наоборот возникает довольно часто. И в Java нет встроенной функции для этого. И в конечном итоге вы закончите использовать valueOf () и toString (). И использование этого подхода не будет сильно отличаться от использования простых строк. Потому что вам нужно будет обрабатывать ситуации, когда строка не может быть преобразована в Enum.
Так что просто использовать статические конечные строки легко и это обычная практика, AFAIK.
Например, вы хотите взаимодействовать с сервером, используя некоторый API. Вам нужно будет определить каждый метод и ответ как Enum. И тогда вам нужно будет добавить методы toString и valueOf. Почему бы просто не использовать String?
@Martin: Я думаю о сравнении входных данных с String const, иначе будет выдано недопустимое исключение ввода, что нехорошо. Я задал вопрос из-за предложения открытых ключей, это, похоже, уменьшает концепцию WORA в Java.