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

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

isEveryStoreOpen() or isEachCatCute()

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

Соглашение состоит в том, чтобы префикс метода-получателя «есть», а не сам вариале.

e.g.

private boolean enabled;

public boolean isEnabled() {
    return enabled;
}

и

private boolean storesOpen;

public boolean isStoresOpen() {
    return storesOpen;
}

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

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

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

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

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

Что вы кодируете, английский или Java?

Когда я читаю код Java, я ожидаю, что он будет структурным. Логические методы, начинающиеся с is, являются хорошей структурой.

return 0; 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здесь

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

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

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

Не так, как ваше английское множественное число true's или false's.

Не массив true или false или набор true или false.

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

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

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