Getters booléens Java "est" vs "sont"

Je sais que la convention en Java pour les getters booléens est d'inclure le préfixe "est".

isEnabled
isStoreOpen

Mais que faire si le sujet est pluriel? Autrement dit, et si au lieu de vouloir savoir si un magasin est ouvert, je voulais savoir si tous les magasins sont ouverts?

isStoresOpen() n'a pas de sens en anglais.

Je suis tenté d'écrire des getters comme:

areStoresOpen
areDogsCute
areCatsFuzzy

Et je pense que ce serait logique, mais on m'a dit par d' autres que je devrais juste sucer et abandonner sujet verbe accord et à l' utilisation isStoresOpen, isDogsCute, isCatsFuzzy.

Quoi qu'il en soit, que dois-je faire pour les getters booléens qui opèrent sur un sujet pluriel?

Je ne me souviens pas de quel livre il s'agissait, mais l'essentiel est que le code sera lu beaucoup plus de fois qu'il n'est écrit. Écrivez pour plus de lisibilité.

Que diriez-vous d'avoir un anglais assez décent et de suivre la norme Java:

isEveryStoreOpen() ou isEachCatCute()

En cas de doute sur le mot juste, j'aime toujours consulter le thésaurus.

La convention est de préfixer la méthode getter avec "is" et non la variable elle-même.

par exemple

private boolean enabled;

public boolean isEnabled() {
    return enabled;
}

et

private boolean storesOpen;

public boolean isStoresOpen() {
    return storesOpen;
}

isStoresOpen () n'a pas de sens en anglais.

Cela n'a peut-être pas de sens grammaticalement, mais il suit la convention et semble suffisamment lisible.

La spécification Java Bean dit d'utiliser getpour les getters à moins que ce ne soit une booleanutilisation alors is. aren'est pas standard et ne sera pas reconnu par tout ce qui attend une dénomination Bean standard.

De nombreux outils s'attendent isou getne reconnaîtront probablement pas are.

Essayez de les reformuler, comme getDogsAreFuzzy()ou getStoresAreOpen()ou des choses comme ça pour une meilleure compatibilité et des conventions.

- isEnabled() peut également être écrit comme getEnabled()dans Java naming conventions.

- C'est juste une bonne habitude de suivre les conventions de dénomination, de l'aide lorsque vous travaillez avec Java Beans.

En général, je pense que le code devrait être aussi facilement lisible que possible afin qu'une méthode puisse presque être lue comme un paragraphe (comme le préconise Clean Code). Par conséquent, je nommerais la méthode pour sonner / lire aussi facilement que possible et suivre la règle de grammaire de are. Avec les IDE modernes, il est facile de trouver des méthodes sans chercher spécifiquement get/ is.

Cependant, Kumar fait un bon point sur les haricots. De nombreux outils ne rechercheront que get/ is. Dans ce cas, je pourrais envisager d'utiliser les deux méthodes. Un pour la facilité de lecture et un pour l'utilisation des outils.

Dans quelle langue écrivez-vous: anglais ou Java ?

Quand je lis du code Java, je m'attends à ce que les choses soient là, me demander de rechercher les deux getters, avec les préfixes is et are , sera plus compliqué que de rechercher un seul préfixe.

Cependant d'un autre côté, quand je lis le journal le matin, je ne cherche rien, donc vous pouvez écrire de manière plus traditionnelle en anglais.

return 0;

Dans votre question, vous posez explicitement des questions sur les getters. Un getter renvoie des informations sur une instance de votre classe. Par exemple, vous avez une classe Store. Maintenant, isStoreOpenc'est un nom de méthode parfaitement parfait pour un getter.

Ensuite, vous mentionnez une méthode qui vérifie si tous les magasins sont ouverts. Cette méthode n'est pas du tout un getter, car elle ne renvoie pas d'informations sur une instance mais pour toutes. Bien sûr, à moins qu'il y ait une classe Stores. Si tel est le cas, vous devriez repenser votre conception, car Java a déjà des moyens de stocker un certain nombre d'instances, par exemple des tableaux ou des collections, vous n'avez donc pas à écrire de classes supplémentaires.

Si ce n'est pas le cas, alors ce nom de méthode convient parfaitement. Une alternative peut être juste allStoresOpensans le «est».

TL; DR: Si vous avez affaire à plusieurs instances, ce n'est pas un getter. Si c'est le cas, votre conception est mauvaise.

Très honnêtement, je dirais certainement oublier are*et rester fidèle is*. Considérez le "is"comme la signification de la variable et faites un meilleur nom si possible.

Je dirais que isStoresOpen ne sonne pas si mal, mais vous pouvez créer isStoresAreOpen si cela vous convient mieux.

Mais mon idée générale serait de m'en tenir aux conventions. Qui utilise "get" pour les getters et "is" pour les types booléens. Personnellement, je pense que l'utilisation de «est» est parfois déjà problématique. Oui - cela a l'air bien dans les conditions "si", mais parfois j'écris simplement "obtenir" lors du codage et je vérifie la liste déroulante pour ma variable nécessaire et je commence à me demander ce qui ne va pas et pourquoi je ne peux pas le trouver, alors je le réalise commence par "est" ...

Dans la programmation orientée objet, cela devrait rarement, voire jamais, se produire puisque Storeou Catou quoi que ce soit, vous devriez être une classe séparée, avec sa propre méthode isOpen()ou isFuzzy(). Si vous avez un type supérieur, envisagez de le diviser au niveau le plus atomique que vous utilisez réellement. En général, les objets ne doivent pas être au pluriel au niveau le plus bas.

isStoresOpen () dans ce StoresOpen ressemble à un pluriel,

Lorsque vous suivez cette convention de dénomination Java et les normes Java Beans, ils ont des préfixes prédéfinis pour les types booléens et autres, vous devez donc suivre la convention de dénomination des Java Beans.

Venons- en à votre argument Quand vous voyez storesOpen comme dans une perspective anglaise, oui ça ressemble au pluriel. Encore une fois, observez profondément ce mot,

Ici

storesOpen est le pluriel selon la grammaire anglaise,

Le résultat de isStoresOpen n'est pas pluriel, au lieu d'être singulier ou vous pouvez dire qu'il est scalaire en termes de convention de programmation.

Il est sorti est booléen, juste vrai ou faux

Pas comme votre énoncé pluriel anglais vrai ou faux

Pas un tableau de vrai ou faux , ou pas une collection de vrai ou faux

Donc, ici, nous pouvons dire que, ici, nous sommes concernés par la valeur renvoyée par cette méthode booléenne, et non par le nom donné à la propriété de classe pour pointer l'entité du monde réel.

Une chose plus importante est que chaque fois que de telles propriétés booléennes sont utilisées dans des classes et que celles-ci sont utilisées par des bibliothèques prédéfinies dans n'importe quel framework, alors le framework avec le préfixe d'utilisation `` est '' pour récupérer des valeurs booléennes,

pourquoi cela signifie que ce n'est pas tellement plus intelligent que vous car vous connaissez la grammaire anglaise comme le pluriel / singulier, le multiplexeur, etc.