Как вы определяете класс констант в Java?

Используйте последний класс. для простоты вы можете затем использовать статический импорт для повторного использования ваших значений в другом классе

public final class MyValues {
  public static final String VALUE1 = "foo";
  public static final String VALUE2 = "bar";
}

в другом классе:

import static MyValues.*
//...

if(variable.equals(VALUE1)){
//...
}

В вашем пояснении: «Я не буду использовать перечисления, я ничего не перечисляю, а просто собираю некоторые константы, которые никак не связаны друг с другом».

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

Мои предложения (в порядке убывания предпочтения):

1) Не делайте этого. Создайте константы в реальном классе там, где они наиболее актуальны. Наличие класса / интерфейса «мешка констант» на самом деле не соответствует лучшим практикам объектно-ориентированного проектирования.

Я, как и все остальные, время от времени игнорирую №1. Если вы собираетесь это сделать, то:

2) final класс с частным конструктором. Это, по крайней мере, предотвратит злоупотребление вашим «набором констант» путем его расширения / реализации, чтобы получить легкий доступ к константам. (Я знаю, вы сказали, что не сделаете этого, но это не значит, что кто-то придет после вас)

3) интерфейс. Это будет работать, но я не предпочитаю упоминать о возможном злоупотреблении в пункте 2.

В общем, то, что это константы, не означает, что вы не должны применять к ним обычные принципы oo. Если никто, кроме одного класса, не заботится о константе - она ​​должна быть закрытой и принадлежать этому классу. Если только тесты заботятся о константе - она ​​должна быть в тестовом классе, а не в производственном коде. Если константа определена в нескольких местах (а не просто случайно в одном и том же) - произведите рефакторинг, чтобы исключить дублирование. И так далее - относитесь к ним, как к методу.

Как отмечает Джошуа Блох в Effective Java:

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

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

class SomeConstants
{
    // Prevents instanciation of myself and my subclasses
    private SomeConstants() {}

    public final static String TOTO = "toto";
    public final static Integer TEN = 10;
    //...
}

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

Я предпочитаю вообще этого не делать. Возраст констант практически умер, когда в Java 5 были введены типы безопасных перечислений. И еще до этого Джош Блох опубликовал (немного более многословную) версию этого, которая работала на Java 1.4 (и ранее).

Если вам не нужна совместимость с каким-либо унаследованным кодом, действительно нет причин использовать именованные строковые / целочисленные константы.

Просто используйте последний класс.

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

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

Не являются перечисления лучшим выбором для этих какие вещи?

enums в порядке. IIRC, один элемент в эффективной Java (2-е изд.) Имеет enum константы, перечисляющие стандартные параметры, реализующие [ключевое слово Java] interface для любого значения.

Я предпочитаю использовать [ключевое слово Java] interface вместо final class для констант. Вы неявно получаете public static final. Некоторые люди будут утверждать, что interface позволяет плохим программистам реализовать его, но плохие программисты будут писать отстойный код, что бы вы ни делали.

Что выглядит лучше?

public final class SomeStuff {
     private SomeStuff() {
         throw new Error();
     }
     public static final String SOME_CONST = "Some value or another, I don't know.";
}

Or:

public interface SomeStuff {
     String SOME_CONST = "Some value or another, I don't know.";
}

Или 4. Поместите их в класс, содержащий логику, которая больше всего использует константы.

... извините, не удержался ;-)

Лучший подход для меня - enum:

public enum SomeApiConstants {;

    public static final String SOME_CONST = "SOME_VALUE";

    //may be in hierarchy
    public enum ApiMapping {;
        public static final String VERSION = "/version";
        public static final String VERSION_LIST = "/list/{type}";
    }
}

Плюсы:

• чистый код
• частный конструктор не нужно определять
• попытка создать экземпляр проверяется во время компиляции как java: enum types may not be instantiated
• предотвращает клонирование и десериализацию

1. Одним из недостатков частного конструктора является то, что метод не может быть протестирован.

2. Enum по своей природе хорошо подходит для применения в конкретном типе домена, его применение к децентрализованным константам выглядит недостаточно хорошо

Концепция Enum такова: «Перечисления - это наборы тесно связанных элементов».

3. Расширять / реализовывать постоянный интерфейс - плохая практика, трудно думать о необходимости расширять неизменяемую константу вместо того, чтобы ссылаться на нее напрямую.

4. Если применить качественный инструмент, такой как SonarSource, есть правила, вынуждающие разработчика отказаться от постоянного интерфейса, это неудобно, поскольку многие проекты пользуются постоянным интерфейсом и редко можно увидеть, как что-то «расширяется» на постоянных интерфейсах.