Вопрос по java – 'public static final' или 'private static final' с геттером?

44

В Java учат, что переменные должны оставаться закрытыми, чтобы обеспечить лучшую инкапсуляцию, но как насчет статических констант? Это:

public static final int FOO = 5;

Было бы эквивалентно в результате этого:

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

Но какая практика лучше?

Голосование по закрытию неконструктивно (на основе уже высказанных мнений). ЯвляетсяFOO действительно постоянная? Класс обеспечиваетFOO часть API? Или часть приложения конечной точки? Есть математические константы, которые никогда не меняются. Есть также битовые флаги, которые никогда не должны изменяться (см. SWT). Таким образом, ответ "Это зависит." Tim Bender

Ваш Ответ

7   ответов
7

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

Error: User Rate Limit Exceeded
3

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

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

57

де.

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

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

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Chris Cummins
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit ExceededPiError: User Rate Limit Exceeded
0

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

2

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

public def FOO:Integer = 5; 

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

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

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

0

жности перезаписи. Это недопустимо для статических "методов" (скорее функции)

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

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

0

если результат getFoo является затратным и не требует оценки во время выполнения.

Похожие вопросы