Логические геттеры Java «есть» против «есть»

92

Я знаю, что соглашение в Java для логических получателей включает префикс «is».

isEnabled
isStoreOpen

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

isStoresOpen() не имеет смысла на английском.

Мне очень хочется написать геттеры вроде:

areStoresOpen
areDogsCute
areCatsFuzzy

И я думаю , что будет иметь смысл, но мне сказали , другие , что я должен просто сосать его и отказаться от предмета глагола соглашения и использования isStoresOpen, isDogsCute, isCatsFuzzy.

В любом случае, что мне делать с логическими геттерами, которые работают с субъектом множественного числа?

кодай
источник
3
Я никогда раньше не видел are*()добытчиков.
rekire
21
Я всегда пишу are*()геттеры, если они грамматически правильные.
Родди из Frozen Peas
2
Если ваш объект боб, я думаю , вы должны придерживаться либо isили has...
assylias
4
если вы используете getter are * (), то в большинстве случаев он должен возвращать boolean [].
Juvanis
2
Очень хороший вопрос. Я сам довольно много думал об этом. Как уже отмечалось во многих ответах, большинство фреймворков, IDE и всего, что полагается на соглашение, с которым я столкнулся, используют шаблон «get» / «set» / «is». Даже если это не является проблемой в вашем приложении, я бы следовал этому соглашению независимо - вашему коду будет намного легче следовать (даже вами), если вы будете поддерживать согласованное соглашение об именах (даже если оно иногда не звучит грамматически странно. ).
Пол Рихтер

Ответы:

58

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

Джон
источник
21
Чистый код - Роберт Мартин
Джон Б.
Джон Б: Я не читал эту книгу; возможно я читал ссылку на это. Впрочем, еще одна книга для моего списка. :)
Джон
8
Но будьте очень осторожны, не заходите слишком далеко. storesAreOpen()вероятно, будет наиболее грамматическим (из-за if(storesAreOpen())), но логическая часть имени теперь скрыта в середине имени метода, что нарушает соглашения Java и читаемый код.
Izkata
3
Он отвечает на вопрос в очень общем виде. Верно, что он не говорит о деталях, но это ответ. Это может показаться банальным, но в этом есть ценность (так думают как минимум 24 человека).
Джордж Стокер
4
чтобы уточнить ответ, я бы добавил замечание, что areStoresOpen () - хороший выбор здесь.
kiedysktos
96

Как насчет того, чтобы иметь достаточно приличный английский и следовать стандарту Java:

isEveryStoreOpen() или isEachCatCute()

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

satur9nine
источник
19
+1, это ясно показывает, означает ли возвращаемое значение isEveryStoreOpen () или isAnyStoreOpen () в отличие от неоднозначного isStoresOpen ().
Imre
5
+1 Это должен быть принятый ответ! Имеет смысл грамматически, сохраняя при этом в Java booleanсек isпрефикс конвенции. Кроме того, он предоставляет небольшую дополнительную информацию, которая будет действительно полезна для тех, кто не является носителем английского языка, но которые, как оказалось, поддерживают кодовую базу.
Higuaro
1
Этот ответ изменил мою жизнь! И это должен быть принятый ответ.
Марсель Бланк
34

По соглашению к методу-получателю добавляется префикс "is", а не к самой переменной.

например

private boolean enabled;

public boolean isEnabled() {
    return enabled;
}

а также

private boolean storesOpen;

public boolean isStoresOpen() {
    return storesOpen;
}

isStoresOpen () не имеет смысла на английском языке.

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

Бхеш Гурунг
источник
Ваш ответ имеет смысл, и я ценю это. Я считаю, что с авторитетной позиции "правильно / неправильно" вы правы. Я просто не хочу, чтобы конвенция, которая должна была помочь нам, будучи очевидной, ясной и простой для понимания, отказалась от этой цели ради соблюдения ее правил. Но вы правы - так оно и есть, и я об этом спросил.
kodai
@kodai: Я думаю, это не следует рассматривать как правило, а просто условность. Но я считаю, что написание кода, не следуя соглашению, если это не требуется, сделать код читаемым - это правильный путь.
Bhesh Gurung
18

В спецификации Java Bean говорится, что нужно использовать getдля геттеров, если только он не используется booleanзатем is. areявляется нестандартным и не распознается ничем, ожидающим стандартного именования Bean.

Стив Куо
источник
17

Многие инструменты ожидают isили getне распознают are.

Попробуйте перефразировать их, например, getDogsAreFuzzy()или getStoresAreOpen()что-то подобное для лучшей совместимости и условностей.

Кевин Рубин
источник
Да. Такие инструменты , как боб утилита рассчитывать на слово это , чтобы найти логические добытчик.
nalply
4

- isEnabled() также можно записать как getEnabled()в Java naming conventions.

- Это просто хорошая привычка следовать соглашениям об именах, помогает, когда вы работаете Java Beans.

Кумар Вивек Митра
источник
3

В общем, я считаю, что код должен быть настолько легко читаемым, насколько это возможно, чтобы метод можно было читать почти как абзац (как это принято Clean Code). Поэтому я бы назвал метод максимально простым звуком / чтением и следовал правилу граммера are. В современных IDE легко найти методы, не ища специально get/ is.

Однако Кумар хорошо подмечает бобы. Многие инструменты будут искать только get/ is. В этом случае я мог бы рассмотреть возможность использования обоих методов. Один для удобства чтения и один для использования инструментов.

Джон Б.
источник
3

На каком языке вы пишете: английский или Java ?

Когда я читаю код Java, я ожидаю, что что-то там будет, и заставить меня искать оба геттера с префиксами is и are будет сложнее, чем искать только один префикс.

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

возврат 0;

Илья Газман
источник
3

В вашем вопросе вы явно спрашиваете о геттерах. Получатель возвращает некоторую информацию об одном экземпляре вашего класса. Например, у вас есть класс Store. Теперь isStoreOpenэто прекрасное имя метода для геттера.

Затем вы упоминаете метод, который проверяет, все ли магазины открыты. Этот метод вообще не является геттером, потому что он возвращает информацию не об одном экземпляре, а обо всех. Конечно, если нет класса Stores. Если это так, вам следует переосмыслить свой дизайн, потому что в Java уже есть способы хранения ряда экземпляров, например массивов или коллекций, поэтому вам не нужно писать дополнительные классы.

Если это не так, тогда это имя метода прекрасно. Альтернатива может быть просто allStoresOpenбез «есть».

TL; DR: если вы имеете дело с несколькими экземплярами, это не геттер. Если это так, ваш дизайн плохой.

Кирилл Рахман
источник
2

Честно говоря, я бы сказал, что забудьте об этом are*и придерживайтесь is*. Думайте об этом "is"как о значении переменной и, если возможно, придумайте лучшее имя.

Я бы сказал, isStoresOpen звучит не так уж плохо, но вы можете сделать isStoresAreOpen, если это звучит лучше для вас.

Но моя общая идея - придерживаться условностей. Который использует get для геттеров и is для логических типов. Лично я думаю, что использование «есть» иногда уже проблематично. Да, это действительно хорошо выглядит в условиях «если», но иногда я просто пишу «получить» при кодировании, проверяю раскрывающийся список для моей необходимой переменной и начинаю думать, что не так и почему я не могу ее найти, тогда я понимаю это начинается с "есть" ...

Артурас М
источник
1

В объектно-ориентированном программировании это должно происходить редко, если вообще когда-либо, поскольку Storeили Catили то, что у вас должно быть отдельным классом, со своим собственным методом isOpen()или isFuzzy(). Если у вас более высокий тип, подумайте о разделении на более атомарный уровень, который вы фактически используете. В общем, объекты не должны быть множественного числа на самом низком уровне.

астери
источник
1

isStoresOpen () в этом StoresOpen выглядит как множественное число,

Когда вы следуете этому Соглашению об именах Java и Стандартам Java Beans, у них есть предопределенные префиксы для логических и других типов, поэтому вы должны следовать Соглашению об именах Java Beans.

Давайте перейдем к вашей точке зрения. Когда вы видите, что storeOpen означает «перспектива» на английском языке, да, это похоже на множественное число. Еще раз глубоко понаблюдайте за этим словом,

Вот

storeOpen - это множественное число согласно английской грамматике,

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

Это логическое значение, просто правда или ложь

В отличие от вашего английского множественного числа, истинного или ложного.

Не массив истинных или ложных , или не набор истинных или ложных

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

Еще одна важная вещь: всякий раз, когда такие логические свойства используются в классах и они используются предопределенными библиотеками в любой структуре, тогда структура с префиксом использования ' is ' для получения логических значений,

почему это означает, что он не намного умнее вас, поскольку вы знаете грамматику английского языка, такую ​​как множественное / единственное число, мультиплексор и т. д.

Анил Кумар
источник