Ik weet dat de conventie in Java voor booleaanse getters het voorvoegsel “is” bevat.

isEnabled
isStoreOpen

Maar wat als het onderwerp meervoud is? Dat wil zeggen, wat als ik in plaats van te willen weten of een winkel open is, wil weten of alle winkels open zijn?

isStoresOpen()is niet logisch in het Engels.

Ik kom in de verleiding om getters te schrijven als:

areStoresOpen
areDogsCute
areCatsFuzzy

En ik denk dat dat logisch zou zijn, maar anderen hebben me verteld dat ik het gewoon moet opzuigen en de overeenkomst tussen het onderwerp en het werkwoord moet opgeven en isStoresOpen, isDogsCutemoet gebruiken. , isCatsFuzzy.

Hoe dan ook, wat moet ik doen voor booleaanse getters die werken op een meervoudig onderwerp?

Antwoord 1, autoriteit 100%

Wat dacht je ervan om voldoende Engels te hebben en de Java-standaard te volgen:

isEveryStoreOpen()of isEachCatCute()

Bij twijfel over het juiste woord sla ik altijd graag de thesaurus in.

Antwoord 2, autoriteit 52%

Ik kan me niet herinneren uit welk boek dit kwam, maar de essentie is dat code veel vaker zal worden gelezen dan geschreven. Schrijf voor leesbaarheid.

Antwoord 3, autoriteit 30%

De conventie is om de getter-methode vooraf te laten gaan door “is”, niet de variale zelf.

bijv.

private boolean enabled;
public boolean isEnabled() {
    return enabled;
}

en

private boolean storesOpen;
public boolean isStoresOpen() {
    return storesOpen;
}

isStoresOpen() is niet logisch in het Engels.

Het is grammaticaal misschien niet logisch, maar het volgt de conventie en ziet er voldoende leesbaar uit.

Antwoord 4, autoriteit 16%

De Java Bean-specificatie zegt om gette gebruiken voor getters, tenzij het een booleanis, gebruik dan is. areis niet-standaard en wordt niet herkend door iets dat standaard Bean-naamgeving verwacht.

Antwoord 5, autoriteit 14%

Veel tools verwachten isof geten zullen arewaarschijnlijk niet herkennen.

Probeer ze anders te formuleren, zoals getDogsAreFuzzy()of getStoresAreOpen()of dergelijke dingen voor betere compatibiliteit en conventies.

Antwoord 6, autoriteit 5%

Wat codeert u, Engelsof Java?

Als ik Java-code lees, verwacht ik dat dingen structureel zijn. Booleaanse methoden die beginnen met isis een goede structuur.

return 0; 

Antwoord 7, autoriteit 3%

–isEnabled()kan ook worden geschreven als getEnabled()in Java naming conventions.

–Het is gewoon een goede gewoonte om de naamgevingsconventies te volgen, hulp bij het werken met Java Beans.

Antwoord 8, autoriteit 2%

Over het algemeen denk ik dat code zo gemakkelijk mogelijk leesbaar moet zijn, zodat een methode bijna als een alinea kan worden gelezen (zoals omarmd door Clean Code). Daarom zou ik de methode om zo gemakkelijk mogelijk te klinken / lezen een naam geven en de grammaticaregel van arevolgen. Met moderne IDE’s is het gemakkelijk om methoden te vinden zonder specifiek te zoeken naar get/ is.

Kumar heeft echter een goed punt over bonen. Veel tools zoeken alleen naar get/ is. In dat geval zou ik kunnen overwegen om beide methoden te gebruiken. Een voor leesgemak en een voor gebruik met gereedschap.

Antwoord 9, autoriteit 2%

In uw vraag vraagt ​​u expliciet naar getters. Een getter retourneert wat informatie over één instantie van uw klasse. Je hebt bijvoorbeeld een klasse Store. Nu is isStoreOpeneen prima methodenaam voor een getter.

Vervolgens noemt u een methode die controleert of alle winkels open zijn. Deze methode is helemaal geen doorgeefluik, omdat het geen informatie over één instantie retourneert, maar over alle. Natuurlijk tenzij er een klasse Storesis. Als dit het geval is, moet u uw ontwerp heroverwegen, omdat Java al manieren heeft om een ​​aantal instanties op te slaan, b.v. arrays of verzamelingen, zodat u geen extra klassen hoeft te schrijven.

Als dit niet het geval is, is deze methodenaam prima. Een alternatief kan gewoon allStoresOpenzijn zonder de ‘is’.

TL;DR: Als je met meerdere instanties te maken hebt, is dat geen doorgeefluik. Als dat zo is, is je ontwerp slecht.

Antwoord 10, autoriteit 2%

Eerlijk gezegd zou ik zeggen: vergeet de are*en blijf bij is*. Denk aan de "is"als de betekenis van de variabele en maak indien mogelijk een betere naam.

Ik zou zeggen dat isStoresOpen niet zo slecht klinkt, maar je kunt isStoresAreOpen maken als dat beter voor je klinkt.

Maar mijn algemene idee zou zijn om me aan de conventies te houden. Dat is “get” gebruiken voor getters en “is” voor booleaanse typen. Persoonlijk denk ik dat het gebruik van “is” soms al problematisch is. Ja – het ziet er goed uit in “als” -omstandigheden, maar soms schrijf ik gewoon “krijgen” tijdens het coderen en controleer de vervolgkeuzelijst voor mijn benodigde variabele en begin me af te vragen wat er mis is en waarom ik het niet kan vinden, dan realiseer ik me het begint met “is”…

Antwoord 11

Bij objectgeoriënteerd programmeren zou dit zelden of nooit moeten gebeuren aangezien Storeof Catof wat dan ook, een aparte klasse zou moeten zijn, met zijn eigen isOpen()of isFuzzy()methode. Als je een hoger type hebt, overweeg dan om op te splitsen naar het meer atomaire niveau dat je daadwerkelijk gebruikt. Over het algemeen mogen objecten op het laagste niveau geen meervoud zijn.

Antwoord 12

isStoresOpen()in deze StoresOpen lijkt op een meervoud,

Als je die Java-naamgevingsconventie en Java Beans-standaarden volgt, hebben ze vooraf gedefinieerde voorvoegsels voor boolean en andere typen, dus je moet de Java Beans-naamgevingsconventie volgen.

Laten we tot je punt komen
Als je storesOpenziet zoals in een Engelse prospect, ja, dan lijkt het meervoud.
Neem nogmaals een diepe observatie in dat woord,

Hier

storesOpenis meervoud volgens de Engelse grammatica,

De uitkomst van de isStoresOpenis niet meervoud, in plaats van enkelvoud of je kunt zeggen dat het scalair is in termen van programmeerconventie.

Het komt erop neer dat het booleaans is, alleen waar of onwaar

Niet zoals uw Engelse meervoudsverklaring true’sof false’s

Geen array van trueof false, of geen verzamelingen van trueof false

Dus hier kunnen we zeggen dat we ons hier bezighouden met waarde die de terugkeer van die boolean bean-methode is, niet de naam die aan de eigenschap class to point real-world entiteit wordt gegeven.

Nog belangrijker is dat wanneer dergelijke booleaanse eigenschappen worden gebruikt in klassen en deze worden gebruikt door vooraf gedefinieerde bibliotheken in een raamwerk, het raamwerk met gebruiksvoorvoegsel ‘is‘ voor het ophalen van booleaanse waarden,

waarom betekent het dat het niet zo veel slimmer is dan jij, omdat je Engelse grammatica kent, zoals meervoud/enkelvoud, multiplexer enz…