Группировка Связанные Константы Общие между классами

Question

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

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

Существует несколько постоянных интерфейсов в java-платформе , таких как java.io.ObjectStreamConstants. Эти интерфейсы следует рассматривать как аномалии и их нельзя эмулировать.

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

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

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

Answer 1

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

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