Интерфейс только с константами

Question

Недавно я натолкнулся на фрагмент кода, в котором я нашел интерфейс с только константами. И эти константы были доступны в классах с использованием статического импорта. Константы были больше (около 30-50).

Лично я не думаю, что это хорошая практика. Именно поэтому его называют Constant Interface Antipattern в соответствии с действующей Java. У меня нет веских причин для такого кодирования.

Кроме того, статический импорт должен использоваться ТОЛЬКО, если в нашем приложении несколько констант для импорта многими классами.

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

Answer 1

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

Если бы эти константы использовались только в одном классе, то комментарии в других ответах («шаблон, которого следует избегать») вполне допустимы - они были бы наиболее полезны, если бы они были объявлены классом, который их использует.

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

Answer 2

Если эти константы образуют некоторую логическую группу, я мог бы использовать enum вместо

Answer 3

Мне вообще не нравится эта идиома. Почему вы должны отделять константы от контекста, в котором они используются? Я нахожу это запутанным.

Этот дизайн заставляет класс, который хочет, чтобы одна константа реализовала весь интерфейс, переполненный ими. И все эти константы являются публичными.

Идея enum хорошая. Что-нибудь кроме этого.

Answer 4

Распространенной альтернативой является определение общедоступных статических конечных констант в служебном классе, а не в интерфейсе.Возьмите ваш интерфейс констант, переопределите его как класс, поместите «public static final» в каждое объявление и ссылайтесь на эти переменные, квалифицированные по имени класса, а не реализуя интерфейс.констант иначе чем перечисление.

Answer 5

Другой альтернативой (кроме перечисления) будет неинстатируемый класс (частный конструктор) для сбора констант, если перечисление не подходит (например, строки, целые числа и т. Д.).

Плюс, возможно, сделать класс видимым для пакета только там, где он используется.

Answer 6

Совсем нет. Я бы избегал такой схемы всякий раз, когда мог, совсем не в моей книге. Я бы предпочел хранить константы там, где они наиболее понятны или принадлежат им с точки зрения ОО, и это очень редко группируется в интерфейсе.

Answer 7

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

Используя интерфейсы, мы можем создать их целое хранилище и не дублировать их.

Answer 8

по этой ссылке обсуждены эффективные вопросы http://www.theserverside.com/discussions/thread.tss?thread_id=19221

, и суть в том, чтобы избежать как можно большего, используя интерфейсы только с константой