Nommer un champ booléen qui est un verbe

14

En Java, par convention, getter et setter pour les champs booléens seront isField()et setField(). Cela fonctionne parfaitement bien avec les noms de champs qui sont des adjectifs comme active, visible, closed, etc.

Mais comment nommer un champ qui a la signification d'un verbe, comme haveChildren? Ajoutez «_ing» au verbe ( ), peut-être?havingChildren

Pour clarifier, je n'ai pas le contrôle des noms de méthode (getter et setter) car ils sont générés automatiquement par l'IDE. Donc, ce dont j'ai besoin, c'est d'un nom de champ approprié pour que lorsque l'IDE génère un getter pour cela, il ait un sens. Par exemple, hasChildrenest un nom de champ parfait, mais lorsque l'EDI génère le getter pour le champ, ce serait isHasChildren. Comment résoudre ce problème?

java naming

— dnang
source

3

S'il s'agit d'un champ booléen, parentcela fonctionnerait.

— yannis

2

Si vous parvenez à inverser le sens, «sans enfant» ferait l'affaire.

— Kilian Foth,

3

Semble assez idiot d'avoir à sauter à travers des cerceaux concernant le nom d'un champ afin d'éviter un problème grammatical causé par l'IDE. Quoi qu'il en soit, voici quelques suggestions supplémentaires, bien que je pense que celles déjà données par d'autres sont meilleures: isAllowedChildren, isNotEmpty, isContainer, isLeaf,

— Dr. Wily's Apprentice

sans enfant semble être la voie à suivre. Le problème avec le parent est que j'ai déjà un champ parent pour contenir la référence à l'objet parent. Je pense que j'ai besoin d'une règle générale pour convertir tous les verbes en adjectifs pour les champs booléens.

— dnang

1

Je suis d'accord avec @dnhang que vous ne devriez pas laisser un IDE dicter des choses comme ça. Le choix des noms de variable et de méthode est important pour rendre votre code lisible, l'IDE dans lequel il est écrit ne devrait pas être pertinent.

— Digitalex

11

Réponse courte:

les noms de méthode ne sont pas supposés refléter l'implémentation interne mais le comportement attendu.

Longue réponse:

haveChildren()doit être nommé hasChildren().

De plus, je ne vois pas hasChildren()nécessairement être le getter pour un membre de la classe booléenne. Je suppose qu'une telle méthode permettrait de savoir si un membre de type Collectionest vide ou non .

Le nom par défaut qu'un IDE donne aux getters et setters générés ne sont pas censés être une loi gravée dans le marbre.

Autre point: les interfaces ont des noms pour les méthodes encore à implémenter.

Si les noms de méthode étaient supposés refléter l'implémentation interne, comment quelqu'un pourrait-il jamais concevoir une interface? Les interfaces n'ont pas d'implémentation et ne savent pas à l'avance ce que les implémentateurs feront sous le capot.

Prenons par exemple l' Iteratorinterface en Java.

Lorsque vous implémentez Iterator, même si vous avez un membre booléen nommé next, vous n'êtes pas censé arriver à renommer hasNext()à isNext()ou isHavingNext(). C'est un détail d'implémentation. En fait, j'ai implémenté Iteratoret ce que je fais est d'avoir un membre du type de ce que ma classe a une liste, nommé next(pas un booléen). hasNext()revient ensuite next!=null.

Voir aussi ceci:

class patient {
      private boolean pulse;
      private boolean breaths:
      public boolean isDead(){ return (!pulse & !breaths);}
}

Notez que ce isDead()n'est pas un getter normal.

Prenez les outils de productivité des IDE pour ce qu'ils sont.

— Tulains Córdova
source

3

Je suggère de renommer le champ pour parentque le getter soit isParentet le setter le soit setParent.

Vous pouvez également essayer childPresentpour le nom de variable et isChildPresentet setChildPresentcomme getter et setter.

— Thirumalai Parthasarathi
source

1

Même idée que le commentaire de Yannis ci-dessus mais le problème est que j'ai déjà un parentchamp pour contenir la référence à l'objet parent. Je pense que j'ai besoin d'une règle générale pour convertir tous les verbes en adjectifs pour les champs booléens.

— dnang

0

Vous pourriez mettre doesavant le verbe. Comme doesHaveChildrendans votre exemple que vous avez fourni. Ou peut-être shouldHaveChildrenselon le contexte.

— miguel.martin
source

1

Le problème est que je n'ai pas le contrôle du nom de la méthode car le getter et le setter sont générés automatiquement par l'IDE (par exemple Eclipse).

— dnang

1

Renommez simplement la ou les méthodes? Ajoutez un raccourci clavier pour renommer les méthodes (si vous n'en avez pas déjà un).

— miguel.martin

@dnhang si c'est votre code, vous pouvez appeler les méthodes comme vous le souhaitez, indépendamment de ce que l'IDE les appelle lorsqu'il se génère automatiquement.

— Richard

1

@ miguel.martin Une raison pour laquelle vous ne voudriez pas faire cela est Java-beans. L'hypothèse de isSomethingfait partie de cette spécification et de nombreuses hypothèses sont faites autour d'elle, pour le meilleur ou pour le pire, aller à l'encontre de cela avec doesSomethingpeut casser les choses de manière moins évidente, conduisant à des bugs.

0

La question est parfaitement raisonnable. Parfois, renommer la méthode générée automatiquement n'est pas suffisant. Exemple: les beans gérés JSF devraient avoir isXyz()comme méthode getter d'une boolean xyzpropriété.

Je suis d'accord avec BlackPanther qui suggère de renommer le champ parentet de l'utiliser isParentcomme nom de méthode. Selon le principe de masquage des informations, la lisibilité des méthodes getter et setter est plus importante que celle de l'attribut.

— Paulo Merson
source