Работа со спецификаторами доступа на уровне Java по умолчанию - PullRequest
3 голосов
/ 27 мая 2010

Недавно я видел некоторый код в проекте, где некоторые поля в паре классов использовали модификатор доступа по умолчанию без уважительной причины. Это почти похоже на случай "ой, забыл сделать это частным". Поскольку классы используются почти исключительно вне пакета, в котором они определены, поля не отображаются из вызывающего кода и рассматриваются как частные. Так что ошибка / недосмотр была бы не очень заметна.

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

Итак, мои вопросы:

  1. Существуют ли передовые практики, касающиеся спецификаторов доступа по умолчанию, о которых мне следует знать? Что-нибудь, что помогло бы предотвратить повторение подобных аварий?
  2. Существуют ли какие-либо аннотации, которые могли бы что-то сказать о том, что "я действительно хотел, чтобы это был доступ по умолчанию"?
  3. Используя CheckStyle или любые другие плагины Eclipse, есть ли способ помечать экземпляры полей по умолчанию или запрещать любые, не сопровождаемые, скажем, комментарием "// доступ по умолчанию" после них?

Ответы [ 3 ]

2 голосов
/ 27 мая 2010

Что касается стиля, я видел несколько руководств по стилю, которые рекомендуют помещать «пакет» в комментарий, чтобы обозначить, что он был намеренным. Как это:

/*package*/ int myInt;

К сожалению, спецификация языка Java не позволяет явно использовать «пакет»; в конце концов, это уже зарезервированное ключевое слово!

0 голосов
/ 27 мая 2010

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

Если вы решите нарушить это соглашение, вам будет разрешено и вы должны знать, что делаете.Вы знаете, что еще вы можете сделать, чтобы возиться с дизайном, так как у вас есть источник? Все !

Уровень доступа - это, в конце концов, система чести.Он здесь, чтобы помочь вам, но это не ваш диктатор.

Классы JDK широко используют переменные уровня пакета.И это мой любимый тоже.public и protected играют важную роль в публичных API, private, когда вы действительно параноик и даже не доверяете себе.Для всего остального - уровень по умолчанию / уровень пакета, который предоставляет автору свободный доступ, но затрудняет доступ для пользователей.

"Как автор может быть таким высокомерным и думать, что ему не нужно отмечать свою личную информацию?переменные как частные? Он делает свою работу неправильно!- ну, кто ты и как это твое дело?

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

0 голосов
/ 27 мая 2010

Я бы предложил запустить UCDetector на базе кода. С главной страницы:

UCDetector создает маркеры для следующих проблем, которые появляются в представлении проблемы затмения:

  • Ненужный (мертвый) код
  • Код, в котором видимость может быть изменена на защищенную, по умолчанию или частную
  • Методы полей, которые могут быть окончательными
...