Соглашение Java/Guava для использования префикса get?
В проекте, над которым я работаю, мы обсуждаем, когда использовать get (getFoo
) против нормального имени (foo
) в Яве. Когда я оглядываюсь в java core и guava, я вижу, что есть много примеров, где опускается get. Есть ли документ, который описывает, когда guava или новые java API будут использовать префикс get, а когда нет? Есть ли соглашение, которое эти разработчики используют здесь?
Спасибо, что нашли время, чтобы прочитать это.
Примеры:
ByteBuffer: http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html ForwardingObject: http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/collect/ForwardingObject.html Секундомер: http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Stopwatch.html Тикер: http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Ticker.html
РЕДАКТИРОВАТЬ:
По состоянию на http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf: "Java Bean - это программный компонент многократного использования, который может быть манипулировали визуально в инструменте ". В нашей базе кода проблема get vs no get возникает, когда код не имеет ничего общего со значениями или объектами данных (объектами, представляющими данные). Когда класс представляет данные, у нас все в порядке с get.
Мой главный вопрос: почему и java, и guava решили использовать методы non get для объектов, не относящихся к данным, и каковы их соглашения.
2 ответа
get
Префикс взят из JavaBeans Conventions, в котором говорится, что если у вас есть средство доступа к свойству, то имя метода средства доступа должно начинаться с get
, если это не логическое значение (тип примитива), в этом случае следует начинать с is
, Обратите внимание, что вы используете get
префикс для возврата типа Boolean.
На протяжении большей части API Java это соглашение используется, что также было бы моей рекомендацией. Ваше решение зависит от вас, но какую бы конвенцию вы ни выбрали, я бы посоветовал быть последовательным, а не смешивать оба.
Хотя идея отбрасывания "get" привлекательна для меня, проблема возникает, когда у вас также есть сеттер. Вы должны сделать что-то вроде
public String name(); // getter
and
public void name(String newName); // setter, xor use the below **instead** but not both
public Foo name(String newName); // if you prefer fluent/builder style
Который "выглядит странно" для программиста на Java. И до 1 минуты назад я думал, что это незаконно, и мой оригинальный пост ошибочно говорил так, пока я не проверил это. Вы узнаете что-то каждый день...
Добавлено в ответ на @DwB
Одна хорошая причина использовать get/set - это то, что многие сторонние фреймворки ожидают этого соглашения, поскольку они используют рефлексию для рассуждений о вашем классе. Тем не менее, фреймворк может искать комбинации, подобные приведенным выше, или может быть настроен на использование этих методов вместо обычного get/set. Это было почти в моем первоначальном посте, но я не использовал Spring, Hibernate и т. Д. В течение нескольких лет, так что я не в курсе того, что некоторые из них не допустят, если вы не используете get/set,
Например, Джексон может использовать аннотации и миксины для определения отображений, нет необходимости следовать соглашению get/set. Я думаю, что Spring, JSF и т. Д. Могли бы сделать то же самое (кто-то, пожалуйста, отредактируйте этот ответ с подробностями по мере необходимости), хотя с некоторой дополнительной работой. Стоит ли эта дополнительная работа "краткости" устранения get/set, неясно. Я бы сказал нет, но YMMV.