Соглашение Java/Guava для использования префикса 'get'?

Question

В проекте, над которым я работаю, мы обсуждаем, когда использовать get (getFoo) по сравнению с обычным именем (foo) в java. Когда я оглядываюсь в явном ядре и guava, я вижу, что есть много примеров, где get опущен. Есть ли какой-либо документ, который охватывает, когда guava или новые API-интерфейсы java будут использовать префикс get, а когда это не так? Существует ли конвенция, которую эти разработчики используют здесь?

Спасибо, что нашли время, чтобы прочитать это.

Примеры:

ByteBuffer: http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#compact() ForwardingObject: http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/collect/ForwardingObject.html#delegate() Секундомер: http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Stopwatch.html#elapsed(java.util.concurrent.TimeUnit) Код: http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Ticker.html#systemTicker()

РЕДАКТИРОВАТЬ:

По http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf, «Java, Бин является многоразовым программный компонент, который может визуализироваться визуально в инструменте строителя. " В нашей базе кода проблема get vs no get возникает, когда код не имеет ничего общего с объектами ценности или данных (объекты, которые представляют данные). Когда класс представляет данные, мы отлично работаем.

Мой главный вопрос: почему и Java, и Guava предпочитают использовать методы non get для объектов без данных и каковы их соглашения.

Answer 1

Приставка get происходит от JavaBeans Conventions, в котором говорится, что если у вас есть аксессора для свойства, то имя акцесора должен начинаться с get, если это не является логическим (примитивный тип), в этом случае это должно начинаются с is. Обратите внимание, что вы используете префикс get для возврата типа Boolean.

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

Answer 2

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

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

одна хорошая причина, чтобы использовать получить/установить, что многие 3-структуры партии ожидают эту конвенцию, так как они используют отражение рассуждать о классе , Тем не менее, структура может иметь возможность искать комбинации, подобные приведенным выше, или быть сконфигурированным, чтобы использовать эти методы вместо обычного get/set. Это было почти в моем оригинальном посте, но я не использовал Spring, Hibernate и т. Д. Через несколько лет, поэтому я не успеваю на то, что некоторые из них будут не разрешать, если вы не используете get/set ,

Например, Джексон может использовать аннотации и микшины для определения сопоставлений, не нужно следовать соглашению о получении/установке. Я бы подумал, что Spring, JSF и т. Д. Могли бы сделать то же самое (кто-нибудь, пожалуйста, отредактируйте этот ответ с подробной информацией по мере необходимости), хотя и с некоторой дополнительной работой. Неясна ли эта дополнительная работа «краткость» устранения get/set. Я бы сказал, нет, но YMMV.