'public static final' или 'private static final' с getter?

Ответ 1

Есть одна причина не использовать константу прямо в вашем коде.

Предположим, что FOO может впоследствии измениться (но останется неизменным), скажем, public static final int FOO = 10;. Разве что-то не сломалось, пока никто не был настолько глуп, чтобы жестко кодировать значение прямо справа?

Нет. Компилятор Java будет включать в себя константы, такие как Foo выше, в вызывающий код, т.е. someFunc(FooClass.FOO); становится someFunc(5);. Теперь, если вы перекомпилируете свою библиотеку, но не код вызова, вы можете оказаться в неожиданных ситуациях. Этого можно избежать, если вы используете функцию - JIT будет по-прежнему оптимизировать ее просто отлично, поэтому никакой реальной производительности там не было.

Ответ 2

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

Ответ 3

Getter здесь бессмыслен и, скорее всего, будет встроен JVM. Просто придерживайтесь общедоступной константы.

Идея инкапсуляции заключается в защите нежелательных изменений переменной и скрытии внутреннего представления. С константами это не имеет особого смысла.

Ответ 4

Используйте переменные вне класса как:

public def FOO:Integer = 5; 

Если инкапсуляция не является вашим приоритетом. В противном случае используйте второй вариант, чтобы вы выставляли метод, а не переменную.

private static final int FOO = 5;
...
public static getFoo() { return FOO; }

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

Ответ 5

Первый, если результат getFoo является дорогостоящим и не нуждается в оценке во время выполнения.

Ответ 6

Преимущество использования setter и getter на члене - это возможность перезаписывать. Это не относится к статическим "методам" (скорее, к функциям)

Также не существует способа определить статические методы интерфейса.

Я бы пошел с доступом к полю

Ответ 7

Я бы остался с getFoo(), поскольку он позволяет вам изменять реализацию в будущем без изменения кода клиента. Как отметил @Tomasz, JVM, вероятно, включит вашу текущую реализацию, поэтому вы платите большую часть штрафа за производительность.