Группировка связанных констант, совместно используемых между классами

Question

В Effective Java, пункт 17, Джош Блох утверждает, что введение статических элементов в интерфейс (и реализация этого интерфейса) - это плохая практика, известная как Constant Interface Antipattern :

Постоянный шаблон интерфейса - плохое использование интерфейсов. Это класс использует некоторые константы внутри детали реализации. Реализация постоянный интерфейс вызывает это детали реализации просочиться в экспортированный API класса. Нет последствия для пользователей класса что класс реализует константу интерфейс. На самом деле, это может даже перепутать их. Хуже того, он представляет собой обязательство: если в будущем выпуске класс изменен так, что он больше не нужно использовать константы, это все еще должен реализовать интерфейс для обеспечения двоичная совместимость Если нефинал класс реализует постоянный интерфейс, все его подклассы будут иметь свои пространства имен загрязнены константами в интерфейсе.

В платформе Java есть несколько постоянных интерфейсов. библиотеки, такие как java.io.ObjectStreamConstants. Эти интерфейсы следует рассматривать как аномалии и не должны быть эмулированы.

Я вполне уверен, что понимаю причину этого и полностью согласен.

У меня такой вопрос: группировка связанных констант (примечание: они НЕ подходят для перечисления, рассмотрите математический пример связанных констант pi и e) в интерфейсе по сравнению с неинстанцируемым классом, хорошая идея, при условии, что вы получаете доступ к значениям только через статические ссылки и статический импорт, сохраняете взаимодействие скрытым от вашего API с модификатором доступа по умолчанию и никогда не реализуете интерфейс ?

Почему или почему нет? Есть ли какие-либо преимущества в группировании их в классе, кроме возможности использовать закрытый конструктор, чтобы гарантировать, что тип постоянной группы никогда не создается?

Answer 1

Давайте скажем иначе. Нет никакого преимущества использования интерфейсов для констант. Как вы знаете, интерфейсы предназначены для определения контрактов, а не для констант. Я не вижу проблемы замены ключевого слова interface на ключевое слово class и использования, например, полей public static final. Использование интерфейсов для хранения констант никогда не является хорошей идеей. Я думаю, что люди используют этот анти-шаблон, потому что они не знают о статическом импорте (он был представлен в Java 5.0), или им лень отправлять свои константы в соответствующие классы. Вместо этого они просто создают один интерфейс и позволяют каждому классу реализовать его.

Редактировать: Кстати, вопрос звучит так: это хорошая идея, чтобы смотреть телевизор, смотреть телевизор соседского дома с помощью телескопа, если видение хорошее. Ответ прост - нет, телескоп придуман для других вещей. Ах, и я знаю, что этот пример тупой:)