Je sais que la convention dans Java pour les getters booléens est inclut le préfixe "is".
isEnabled
isStoreOpen
Mais que faire si le sujet est pluriel? Autrement dit, que se passe-t-il 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 cela aurait du sens, mais d'autres m'ont dit que je devais simplement le sucer et abandonner l'accord verbal du sujet et utiliser isStoresOpen
, isDogsCute
, isCatsFuzzy
.
De toute façon, 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 suffisamment anglais décent et de suivre Java standard:
isEveryStoreOpen()
ou isEachCatCute()
En cas de doute sur le bon mot, j'aime toujours trouver le thésaurus.
La convention est de préfixer la méthode getter avec "is" et non la variale 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 indique d'utiliser get
pour les getters sauf s'il s'agit d'un boolean
puis d'utiliser is
. are
n'est pas -standard et ne sera pas reconnu par quoi que ce soit qui s'attend à un nom de bean standard.
De nombreux outils attendent is
ou get
et ne reconnaîtront probablement pas are
.
Essayez de les reformuler, comme getDogsAreFuzzy()
ou getStoresAreOpen()
ou des choses comme ça pour une meilleure compatibilité et 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, aidez lorsque vous travaillez avec Java Beans
.
Dans quelle langue écrivez-vous: anglais ou Java?
Quand je lis Java code, je m'attends à ce que les choses soient là, me demandant de rechercher les deux getters, avec est et sont des préfixes , seront plus compliqués que la recherche d'un seul préfixe.
Mais d'autre part, quand je lis le journal le matin, je ne cherche rien, vous pouvez donc écrire de façon plus traditionnelle en anglais.
retourner 0;
En général, je pense que le code doit ê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 pour 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'avoir les deux méthodes. Un pour la facilité de lecture et un pour l'utilisation des outils.
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, isStoreOpen
est un nom de méthode parfaitement fin 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, sauf s'il existe 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, ce nom de méthode convient parfaitement. Une alternative peut être juste allStoresOpen
sans 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.
Dans la programmation orientée objet, cela devrait rarement, voire jamais, se produire depuis Store
ou Cat
ou ce que vous devriez être une classe séparée, avec sa propre isOpen()
ou isFuzzy()
méthode. Si vous avez un type supérieur, envisagez de vous diviser au niveau plus atomique que vous utilisez réellement. En général, les objets ne doivent pas être pluriels au niveau le plus bas.
isStoresOpen () dans ce StoresOpen est ressemble à un pluriel,
Lorsque vous suivez cette Java convention de dénomination et Java Beans Standards, ils ont des préfixes prédéfinis pour les types booléens et autres, vous devez donc suivre Java Convention de dénomination des haricots.
Venons-en à votre point. Lorsque vous voyez storesOpen comme dans une perspective anglaise, oui, cela ressemble au pluriel. Prenez encore une fois une observation profonde dans cette Parole,
Ici
storesOpen est 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.
C'est sorti est booléen, juste vrai ou faux
Pas comme votre énoncé pluriel anglais true's ou false's
Pas un tableau de vrai ou faux, ou pas un ensemble de vrai ou faux
Donc, ici, nous pouvons dire que, ici, nous nous préoccupons de la valeur qui est le retour de cette méthode de bean booléen, pas du 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 'is' pour récupérer les valeurs booléennes,
pourquoi signifie que ce n'est pas beaucoup plus intelligent que vous comme vous le savez la grammaire anglaise comme pluriel/singulier, multiplexeur etc ...
Très honnêtement, je dirais que j'oublie définitivement le are*
et respectez is*
. Pensez au "is"
comme signification de variable et faire un meilleur nom si possible.
Je dirais que isStoresOpen ne sonne pas si mal, mais vous pouvez faire 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 semble bon dans des conditions "si", mais parfois j'écris simplement "get" lors du codage et vérifie la liste déroulante pour ma variable nécessaire et commence à me demander ce qui ne va pas et pourquoi je ne le trouve pas, alors je m'en rends compte commence par "est" ...