Een functienaam die and bevindt zich op het verkeerde abstractieniveau .

Ik neig naar addResponseIdToDB() omdat anders de ‘bijwerking’ een complete verrassing is. Maar:

responseIds = addResponseIdToDB(); 

laat niemand verrast achter.

Het -commando vraagt om het verantwoordelijkheidssegregatieprincipe stelt dat dit niet de enige manier zou moeten zijn om het responseId-object te krijgen. Er moet ook een query zijn die de database die dit object kan ophalen niet verandert.

In tegenstelling tot Bertrand Meyer , denk ik niet dat dit betekent dat de add void moet retourneren. Betekent alleen dat er een equivalente zuivere zoekopdracht zou moeten bestaan en gemakkelijk te vinden zijn, zodat de database niet onnodig wordt misbruikt door het gebruik van statusveranderingsquerys.

_{Aangezien getResponseIds() zou moeten bestaan en niet met de database zou moeten praten, is de beste naam voor een methode die beide doet eigenlijk addToDB(getResponseId()). Maar dat is alleen als je er alle functionele compositie over wilt hebben.}

Opmerkingen

• Toevoegen aan wat er is gezegd, maar als ik een woord toevoeg dat niet ‘ t is gebruikt, zou ik zeggen dat ” en ” is geschikt wanneer een functie iets doet dat atomair is. Als er een voordeel te behalen is uit twee dingen die atomair / samen / tegelijk gebeuren, dan expliciet zijn met wat die twee dingen zijn in de functie naam is goed. Dus ik ben het in het algemeen eens met je eerste stelling, maar ben het zonder enige voorbehoud oneens.
• ” … laat niemand achter verrast. “. Ik ben het daar niet mee eens, ik ‘ ben verbaasd dat een booleaanse variabele en dan moet ik een mentale verschuiving doen om te beseffen dat het toevoegt en alles in één krijgt. Maar ik ben het niet eens met @tintintong dat getAndAddResponseIdsToDB is te lang; het ‘ is ongeveer de helft van de lengte van een groot aantal van mijn functienamen. Als een functie twee dingen doet, zeg dat dan in zijn naam.
• @Luaan OK, waar ga je getAndIncrement naar hernoemen? otherIncrement?
• @Luaan Dus welke waarde retourneert Increment, de waarde pre-increment of post-increment? Het ‘ is niet duidelijk welke het zou zijn zonder in documenten te duiken.Ik denk dat incrementAndGet en getAndIncrement veel betere methodennamen zijn, wat volgens mij een goede zaak is voor ” EN ” in methodenamen, althans in het specifieke geval van methoden die bijwerkingen hebben die de geretourneerde waarde kunnen beïnvloeden.
• @Luaan Als je ” Toename zegt, retourneert de verhoogde waarde ” bedoel je de waarde vóór de verhoging? Ik heb je in eerste instantie verkeerd begrepen .. wat eigenlijk een goed voorbeeld is van waarom getAndIncrement en incrementAndGet betere namen zijn dan alleen increment, zelfs individueel beschouwd

Zoals anderen al hebben gezegd, betekent het gebruik van and in een functienaam automatisch dat een functie ten minste twee dingen doet, wat meestal aangeeft dat hij te veel doet of iets doet op de verkeerde plaats.

Het gebruik van de and -clausule in een functienaam kan naar mijn ervaring echter zinvol zijn als er enkele stappen in een bepaalde stroom zijn die moeten achtereenvolgens worden uitgevoerd of wanneer de hele berekening zinvol wordt.

Bij numeriek rekenen kan dit heel logisch zijn:

normalizeAndInvert(Matrix m)

Ik bedoel, wie weet, toch? Als je wat … bijvoorbeeld verlichtingstrajecten in computergraphics en met een certa in het stadium moet je een bepaalde matrix normaliseren en omkeren, en je merkt dat je constant schrijft:

m = normalize(m), gevolgd door invert(m), net als een eenvoudig voorbeeld, de introductie van de abstractie van normaliseren en omkeren, kan goed zijn vanuit het oogpunt van leesbaarheid.

Semantisch gesproken, dingen als divideAndConquer() etc, wordt waarschijnlijk afgeraden om expliciet te worden uitgeschreven, maar, nou, de And daar is in wezen noodzakelijk.

Opmerkingen

• Functies doen regelmatig meer dan één ding, maar dat zouden kleine dingen moeten zijn die samen een groot ding vormen: ‘ is zinvol op een hoger niveau. normalizeAndInvert kan computeLighting zijn en divideAndConquer kan applyMachiavelli
• Uiteraard 🙂 Gewoon zeggen dat eerst een functie maken met een ” en ” in de naam kan komen als een natuurlijke abstractie op basis van een bepaalde context. Herstructurering via de ” Hernoemen methode ” zou onmiddellijk daarna moeten komen;)
• @BrunoOliveira Behalve soms zijn de twee stappen zelf een onderdeel van veel dingen, hernoemen isn ‘ t de juiste benadering. En zou zeldzaam moeten zijn, maar als je het nooit gebruikt, betekent dit dat je ‘ jezelf herhaalt.

Ik zou zeggen dat het in het algemeen goed is, maar niet in alle gevallen acceptabel is.

Men zou bijvoorbeeld kunnen argumenteren tegen and in een functienaam gebaseerd op het principe van enkele verantwoordelijkheid oftewel de S in SOLID – omdat de and zou kunnen impliceren meerdere verantwoordelijkheden. Als de and echt betekent dat de functie twee dingen doet, dan wil je waarschijnlijk goed nadenken over wat er gebeurt.

Een voorbeeld van een bibliotheek die gebruikt and in functienamen kan worden gevonden in Java “s concurrency en hier and is eigenlijk een heel belangrijk onderdeel van wat er gaande is, en komt nauw overeen met wat je beschrijft in je bericht waar de staat wordt gewijzigd en staat wordt geretourneerd. Er zijn dus duidelijk enkele mensen ( en sommige use-cases) waar het acceptabel wordt geacht.

Reacties

• ” de and kan meerdere verantwoordelijkheden impliceren “. En in dit geval geeft het dat inderdaad aan. De functie haalt ergens antwoord-IDs vandaan, schrijft ze naar een database en retourneert ze. De noodzaak voor dat ” en ” zou inderdaad op zijn minst het idee moeten oproepen bij het OP dat er twee functies nodig zijn: een om de IDs te krijgen en een om ze naar de database te schrijven.
• Hoewel ik het ermee eens ben dat de and een codegeur is, lijkt het basisgedrag legitiem: het is over het algemeen geen slechte idee om wat extra waarde (n) terug te geven van een methode die toevallig noodzakelijke (tussen) resultaten zijn voor het uitvoeren van zijn hoofdfunctie. Als de belangrijkste functie van deze methode is om de respons-IDs aan de database toe te voegen, is het retourneren van de IDs die het heeft toegevoegd aan de beller gewoon een nette, moeiteloze bruikbaarheid van de methode.
• Ik denk niet dat ‘ niet noodzakelijkerwijs in strijd is met SRP. U hebt altijd functies nodig die meerdere dingen doen. Het belangrijkste is dat deze functies een andere functie aanroepen voor alles wat ze willen doen in plaats van de vereiste code rechtstreeks te bevatten.
• Als de functie twee dingen doet, moet de naam dit weerspiegelen.

Inderdaad, dat “is een moeilijke vraag om te beantwoorden, aangezien talrijke commentaren kunnen bevestigen. Mensen lijken tegenstrijdige meningen en adviezen te hebben op wat een goede naam is.

Ik “zou mijn 2 cent willen toevoegen aan deze 2 maanden oude thread omdat ik denk dat ik meer kleuren kan toevoegen aan wat al werd voorgesteld.

Naamgeving is een proces

Dit alles doet me denken aan de uitstekende gids in 6 stappen: Benoemen als een proces .

Een slechte functienaam is er een die verrassend is en je beseft dat je hem niet kunt vertrouwen. Een goede naamgeving is moeilijk om bij het eerste schot goed te krijgen. Het wordt gemakkelijker met ervaring.

6 iteratieve stappen om een goede naam op te bouwen

1. Vervang verrassende naam door overduidelijke onzin zoals appleSauce(). Klinkt gek, maar het is tijdelijk en het maakt duidelijk dat de naam “niet te vertrouwen is.
2. Zoek een eerlijke naam , gebaseerd op wat u begrijpt van wat de functie doet. Stel dat u “de invoeging in het DB-gedeelte nog niet begrijpt, getResponseIdsAndProbablyUseDb zou een optie zijn.
3. Ophalen helemaal eerlijk , dus de functienaam zegt alles wat de functie doet (getAndAddResponseIdsToDB of getResponsesButAlsoAddCacheOfTheResponsesToTheDb van @Fattie zijn geweldige voorbeelden)
4. Ga naar “doet het juiste” wat eigenlijk het gedeelte waar je je functie hebt gesplitst langs de “AND”. Je hebt dus eigenlijk getResponseIds en addResponseIdsToDb.
5. Ga naar een “Intention Revealing” -naam die het punt oplost van “Ik wil altijd het antwoord-ID I ingevoegd in DB nadat ik dit heb gedaan “. Denk niet meer na over de implementatiedetails en bouw een abstractie die de twee kleinste functies gebruikt om iets anders te bouwen. Dit is het hogere abstractieniveau dat wordt genoemd door @candied_orange. xample createResponseIds zou het kunnen en zal de samenstelling zijn van getResponseIds en addResponseIdsToDb.
6. Ga naar uw domein-abstractie . Dit is moeilijk, het hangt af van uw bedrijf. Het kost tijd om naar uw zakelijke taal te luisteren om het goed te krijgen. Uiteindelijk zou je kunnen eindigen met het concept van een Response en Response.createIds() zou logisch zijn. Of misschien is ResponseId iets waardevols en zou je een fabriek hebben om er veel te creëren. Invoegen in DB zou een implementatiedetail zijn van een repository, enz. Ja, het ontwerp zou abstracter zijn. Het zou rijker zijn en je meer laten uitdrukken. Niemand buiten uw team kan u vertellen wat de juiste domein-abstractie in uw situatie zou moeten zijn. Het hangt ervan af .

In jouw geval heb je “1 en 2 al ontdekt, dus je moet waarschijnlijk op zijn minst naar 3 gaan (gebruik” EN “) of verder. Maar verder gaan is niet alleen een kwestie van benoemen, je “zou eigenlijk de verantwoordelijkheden splitsen.

De verschillende suggesties hier zijn dus geldig

In wezen:

• Ja, verrassende functienamen zijn vreselijk en daar wil niemand mee omgaan
• Ja, “EN” is acceptabel in een functienaam omdat het beter is dan een misleidende naam
• Ja, het abstractieniveau is een verwant concept en het is belangrijk

Je hoeft niet meteen voor fase 6 te gaan, het is prima om op fase 2, 3 of 4 totdat je het beter weet!

Ik hoop dat dit nuttig zou zijn om een ander perspectief te geven op wat lijkt op tegenstrijdig advies. Ik geloof echt dat iedereen hetzelfde doel nastreeft ( niet-verrassende namen) maar stoppen bij verschillende stadia, op basis van hun eigen ervaring.

Graag beantwoorden als u vragen heeft 🙂

Je functie doet twee dingen:

1. Krijgt een set IDs via een transformatie en stuurt ze terug naar de beller,
2. Schrijft die set IDs naar een database.

Onthoud het principe van enkele verantwoordelijkheid hier: je zou moeten streven naar een functie één verantwoordelijkheid hebben, niet twee. Je hebt twee verantwoordelijkheden, dus je hebt twee functies:

getResponseIds – Haalt een set IDs op via een transformatie en stuurt ze terug naar de beller
addResponseIdToDB – Neemt een set IDs en schrijft deze naar een database.

En de hele kwestie van hoe je een enkele functie met meerdere verantwoordelijkheden moet noemen, verdwijnt en de verleiding om and in de functienamen te plaatsen, verdwijnt ook.

Als extra bonus, omdat dezelfde functie niet langer verantwoordelijk is voor twee niet-gerelateerde acties, kan getResponseIds uit je opslagplaatscode worden verplaatst (waar het niet hoort aangezien het geen enkele DB-gerelateerde activiteit uitvoert), in een aparte klasse / module op bedrijfsniveau, etc.

Opmerkingen

• Dat ‘ s is zeker waar, maar je merkt dat je een fragment vaak herhaalt met behulp van deze twee SRP-methoden, dan zou je waarschijnlijk een triviale methode moeten schrijven om dit te doen, zodat je DROOG zou moeten ‘ jij?
• @maaartinus, als je merkt dat je deze twee methoden op veel plaatsen aanroept, dan heb je waarschijnlijk een probleem met een gebrek aan samenhang in je code. Het creëren van een ” DRY ” -functie maskeert dan dit gebrek aan samenhang.

Het hebben van een samengestelde functienaam is acceptabel, dus welk naamgevingsschema je gebruikt, hangt af van je context. Er zijn puristen die je zullen vertellen om het uit elkaar te halen, maar ik zal anders argumenteren.

Er zijn twee redenen om dergelijke dingen te vermijden:

• Zuiverheid – Een functie die twee dingen doet, moet worden geconverteerd naar twee functies die elk één ding doen.
• Lexicale grootte – een bigUglyCompositeFunctionName wordt moeilijk te lezen.

Het zuiverheidsargument is typisch het argument waarop de focus ligt. Als een vage algemene heuristiek is het opbreken van functies een goede zaak. Het helpt bij het indelen van wat er gaande is, waardoor het gemakkelijker te begrijpen is. Je zult minder snel “slimme” trucs doen met het delen van variabelen die leiden tot een koppeling tussen de twee gedragingen.

Dus je moet jezelf afvragen “moet ik het toch doen?” Ik zeg dat het opbreken van dingen een vage heuristiek is, dus je hebt eigenlijk alleen een fatsoenlijk argument nodig om ertegen in te gaan.

Een belangrijke reden is dat het gunstig is om de twee operaties als één te beschouwen. Het ultieme voorbeeld hiervan is te vinden in atomaire bewerkingen: compare_and_set. compare_and_set is een fundamentele hoeksteen van atomics (die een manier zijn om multithreading uit te voeren zonder vergrendelingen) die zo succesvol is dat velen bereid zijn om het te beschouwen als de hoeksteen. Er staat een en in die naam. Daar is een heel goede reden voor. Het hele punt van deze operatie is dat het de vergelijking en de instelling doet als één ondeelbare operatie. Als je het opsplitst in compare() en set(), “zou je” de hele reden waarom de functie bestond omzeilen, omdat twee compares() kan rug aan rug voorkomen vóór de set() s.

We zien dit ook in de uitvoering. Mijn favoriete voorbeeld is fastInvSqrt . Dit is een beroemd algoritme van Quake dat 1 / sqrt (x) berekent. We combineren de “inverse” en “vierkantswortel” -bewerkingen omdat dit resulteert in ons een enorme prestatieverbetering. Ze doen een Newtons benadering die beide bewerkingen in een enkele stap uitvoert (en dat gebeurt toevallig in wiskunde met gehele getallen in plaats van met drijvende komma, wat er in het tijdperk toe deed). Als je inverse(sqrt(x)) zou doen, zou het veel langzamer zijn!

Soms is het resultaat duidelijker. Ik heb verschillende APIs geschreven met betrekking tot threading, waarbij men vreselijk voorzichtig moet zijn met zaken als impasses. Ik wilde niet dat mijn gebruiker op de hoogte was van de interne implementatiedetails (vooral omdat ik ze zou kunnen wijzigen), dus schreef ik de API met een paar “en” functies die verhinderden dat de gebruiker ooit een slot voor meer dan één functieaanroep moest vasthouden. Dit betekent dat ze nooit hoefden te weten hoe ik omging met de multithread-synchronisatie onder de motorkap. In feite wisten de meeste van mijn gebruikers “niet eens dat ze zich in een multithread-omgeving bevonden!

Dus hoewel de algemene regel is om dingen uit elkaar te halen, kan er altijd een reden zijn om ze aan elkaar te koppelen. , kan uw gebruiker uw architectuur doorbreken door meerdere keren aan een database toe te voegen zonder de krijgt ertussen? Als elk van de in de database geregistreerde reacties een unieke identificatie moet hebben, kunt u in de problemen komen als de gebruiker ze willens en wetens moet doen neen. Evenzo, zou je ooit een gebruiker willen laten “halen” zonder de resultaten in de database te loggen? Als het antwoord “ja” is, verdeel ze dan zodat de gebruiker toegang heeft tot de “get” -functie. de beveiliging van uw applicatie is verbroken als de gebruiker kan “krijgen” zonder dat het resultaat wordt gelogd in de database, u moet de functies echt bij elkaar houden.

Wat betreft de lexicale kwesties, uw functienaam zou moeten beschrijven wat de gebruiker moet hiervan op de hoogte zijn. Laten we beginnen met het “get” -gedeelte.Het is vrij eenvoudig om de “get” uit een functienaam te verwijderen, omdat al uw voorbeelden een toewijzing tonen: int id = addResponseIdToDB() “. Op alle plaatsen waar de functie wordt gebruikt, eindigt u up en documenteert het feit dat de functie een waarde heeft geretourneerd.

Evenzo kan “toevoegen” optioneel zijn. We gebruiken de term “bijwerking” als een allesomvattende term, maar er zijn verschillende schakeringen van. Als de DB-vermeldingen slechts een logboek zijn, is er mogelijk geen reden om deze te markeren. We zien nooit functies zoals playMusicAndSendPersonalInformationToOurCorporateServers. Het is gewoon playMusic, en als je geluk hebt, kan de documentatie iets vermelden over een socketverbinding via internet. Aan de andere kant, als van gebruikers wordt verwacht dat ze deze functie aanroepen om dingen aan de database toe te voegen, dan is “toevoegen” essentieel. Haal het er niet uit.

Nu, ik heb een heleboel redenen geschreven om elke mogelijke combinatie te doen van wat je vraagt. Ik heb de vraag met opzet niet beantwoord omdat er een keuze moet worden gemaakt. Het is geen regel die je moet volgen. Je bent een API aan het maken.

Dat gezegd hebbende, is mijn instinct dat addResponseIdToDB waarschijnlijk het beste antwoord is. In de meeste gevallen is het “get” -gedeelte een voor de hand liggende bijwerking dat het niet de extra ruis genereert die wordt veroorzaakt door het overal te typen. Er zijn echter een paar plaatsen waar ik het belangrijk zou vinden:

• Als de “get” duur is – Als je een “get” moet doen waarbij je iets via internet moet ophalen en het vervolgens aan een lokale cache-database moet toevoegen, is de “get” in elk geval belangrijk. Het is wat de gebruiker probeert te doen.
• Als u duidelijk moet maken dat de gebruiker moet op de waarde letten. Als de gebruiker de variabele wil gebruiken, zullen ze zich realiseren dat de API deze teruggeeft, en ze zullen het gebruiken. U wilt echter uitkijken voor de gebruiker die niet weet dat hij deze nodig heeft. Als u deze bewerking bijvoorbeeld later met ID moet sluiten om geheugen vrij te maken, wilt u misschien de aandacht vestigen op het feit dat u “doet iets. In deze gevallen wilt u misschien naar een ander werkwoord kijken dan krijgen. “get” impliceert vaak idempotente functies (opnieuw aanroepen doet niets). Als het bronnen retourneert, zijn andere werkwoorden zoals “create” of “verwerven” aardig. Dit specifieke faalmechanisme is een groot probleem in C bij het afhandelen van uitzonderingen . C mist het catch / throw-mechanisme van C ++, dus het vertrouwt op retourcodes. Ontwikkelaars zijn beroemd omdat ze simpelweg niet in staat zijn om deze retourcodes te controleren en daardoor in echt slechte situaties terechtkomen, zoals bufferoverflows.
• Symmetrie – Soms ontwerpt u een API met een lexicale symmetrie. U stelt de woorden zo in dat ze in paren of andere patronen voorkomen, en bewerkt de opdrachten zodat ze gemakkelijk visueel kunnen worden geïdentificeerd of het patroon is gevolgd of niet. Ik zou zeggen dat dit zeldzaam is, maar het is niet ongehoord. Er “is een reden waarom XML-tags sluiten om de tagnaam te herhalen (zoals < foo > en < / foo >).

Reacties

• Voor mensen die niet ‘ Ik ken de wiskunde niet: zowel 1 / x als sqrt (x) zijn nogal trage functies. Met wat slimme wiskunde kunnen we 1 / sqrt (x) sneller dan een deling of een vierkantswortel. Eigenlijk zo veel sneller dat de snelste manier om sqrt (x) te berekenen is om 1 / sqrt (x) te berekenen met een slimme implementatie en het resultaat te vermenigvuldigen met x.
• Zoals in de natuurkunde, waar de elementaire eenheden niet meer meter en seconde zijn, maar seconde en lichtsnelheid, omdat we de lichtsnelheid nauwkeuriger kunnen meten dan de lengte van een meter.

Wat is het ultieme intentie van deze meth od? Waarom zouden deze getransformeerde IDs aan de database worden toegevoegd, is het met het oog op caching? Ik zal onder die aanname werken.

Het klinkt alsof de bedoeling van de methode eigenlijk alleen is om de getransformeerde respons-ids te krijgen (ofwel de transformatie uitvoeren of ze uit een cache halen), en dus is er de naam van uw methode:

getTransformedResponseIds of minder uitgebreid getResponseIds()

Een methode met deze naam kan cachen of misschien niet, en dat kan worden gedocumenteerd, maar de naam van je methode mag je niet “binden aan een specifieke implementatie; Wat als je besluit om te stoppen met het gebruik van een database en ze in plaats daarvan ergens anders in de cache op te slaan, bijvoorbeeld tijdelijk in het geheugen? p> Bijwerkingen zouden precies dat moeten zijn, bijwerkingen, ze zouden waarschijnlijk moeten worden gedocumenteerd, maar ze zouden niet echt de kernintentie (of het succes) of de naam van de functie moeten beïnvloeden. Als het ophalen van de waarde uit de cache mislukt (of als je configureert om caching over te slaan), zou dat geen kritiek probleem moeten zijn, dan zou de methode gewoon transparant opnieuw moeten berekenen, cachen (of niet), en de nieuwe waarde teruggeven.

Soms is het gebruik van een “AND” handig om de bedoeling over te brengen, zoals met de Java-methoden getAndIncrement en incrementAndGet dat “is zeker niet van tafel.

Je zegt dat de functie iets teruggeeft” van een transformatie, niet van elke db-actie “.

Dit suggereert dat de functie zich meer gedraagt als een constructor dan als een getter. constructors zouden echter ook geen bijwerkingen mogen veroorzaken (bedankt voor de link, @ MechMK1 ).

Fabrieksmethoden aan de andere kant veronderstellen al een zekere mate van rommeligheid . Een van de redenen voor het gebruik van fabrieksmethoden is bijvoorbeeld dat een fabrieksmethode:

Biedt meer leesbare code in gevallen waarin meerdere constructors bestaan, elk voor een andere reden. – wikipedia

Evenzo

Als u wat werk met bijwerkingen moet doen, kan een fabrieksmethode zo worden genoemd dat het duidelijker is wat die bijwerkingen zijn. – ruakh

Overweeg om van de functie een fabrieksmethode te maken, door de term “gelogd” te gebruiken om programmeurs te waarschuwen voor de databaseopslag:

• Verklaring: createLoggedResponseid(...) {...} // log object to db
• Bellen: responseid = createLoggedResponseid(...);

Reacties

• Constructeurs mogen geen bijwerkingen veroorzaken
• @ MechMK1 Ik heb ‘ bewerkt om de suggestie van de constructor te verwijderen en om meer ondersteuning te bieden voor een fabrieksmethode met de juiste naam. Laat me weten wat je denk na.