Det er bevist at vi bruker mer tid på å lese kode enn vi gjør på å skrive den, så du kan være sikker på at gode navn vil lønne seg i fremtiden.
Et av de vanligste problemene for utviklere er navngivning. Jeg kan ikke telle hvor mange timer jeg har brukt på å tenke på hvordan jeg skal navngi ting og hvor mange timer det tok meg å forstå kode som inneholdt dårlige navn. Det spiller ingen rolle om det var et objekt, en metode, en klasse eller noe annet. Det er bevist at vi bruker mer tid på å lese kode enn vi gjør på å skrive den, så gode navn lønner seg alltid i fremtiden.
Å bruke gode navn gjør koden din bedre og renere. Det hjelper deg å intuitivt identifisere hva ansvarsområdene til hver del av koden er. Det gjør applikasjonen din enkel å lese i fremtiden av andre utviklere, så vel som av deg selv.
I løpet av de neste minuttene vil jeg gjerne forklare viktigheten av gode navn og dele noen nyttige tips for å finne gode navn.
Nivå av Abstraksjon
Metoder og variabler bør navngis etter hva de betyr. Før du gir et navn, vurder hva ansvaret til den koden er.
La oss vurdere tilfellet med en metode som returnerer en streng med avstanden mellom Warszawa og Paris.
Det er enkelt og ser ut til å fungere riktig, men hva om vi endrer kravene litt? Nå vil jeg ha muligheten til å vise setningen på to forskjellige måter: i kilometer og miles. For å gjøre det må jeg introdusere en variabel til klassen. Denne variabelen vil bli brukt til å erstatte ordet km i to_s-metoden.
Den nye variabelen bør navngis på ett nivå av abstraksjon høyere enn verdiene dens. Det betyr at vi må tenke på formålet med variabelen først. Det vil hjelpe oss å gi den et mer generelt navn, som ikke bør være for vagt samtidig. Oppsummert dette punktet, må navnet antyde formålet med variabelen, men ikke dens mulige verdier.
Så hva er ansvaret til vår nye variabel? Den skal introdusere ordene km eller mi til objektet. Så navnet kan være: kilometers_or_miles, men dette er akkurat samme nivå av abstraksjon som verdiene dens. Hvis vi ønsket å legge til muligheten for å bruke en annen enhet (for eksempel dager), ville navnet kilometers_or_miles vært feil. Vi bør vurdere noe mer generelt. Kilometer og miles er måleenheter, så et godt navn ville være unit. Det er på ett nivå av abstraksjon høyere (mer generelt) enn variabelens ansvar. Derfor ser den nye klasseimplementeringen slik ut:
Den andre tingen er at avstanden mellom Warszawa og Paris faktisk er 1591 kilometer, men det er også 988 miles. Så det er på tide å implementere en metode som returnerer riktig verdi. Regelen er den samme som med unit-variabelen. La oss tenke på betydningen først. Den nye metoden forventes å returnere verdiene 1591 eller 988 som representerer avstanden mellom Warszawa og Paris. Det spiller ingen rolle hvordan metoden vil gjøre jobben sin. Vi kunne kalt den distance_warsaw_paris, men det er på samme nivå av abstraksjon som den returnerte verdien. Det betyr at navnet på metoden antyder mulige returnerte verdier. Denne måten å navngi på er for detaljert.
I fremtiden kan byene endres til andre, for eksempel: New York og London. Derfor vil navnet distance_warsaw_paris bli foreldet, og å endre det på alle steder vil medføre høye kostnader. Den beste løsningen er å kalle den distance. Det er akkurat det vi ønsket — ett nivå av abstraksjon høyere enn kropp av metoden.
Etter denne prosedyren ser de to metodene våre slik ut:
Nivå av Abstraksjon og Klassedeklarasjoner
Metoder og variabler bør navngis på ett nivå av abstraksjon høyere enn innholdet, men navngivning av klasser er en annen sak. Når vi oppretter en klasse, trenger vi ikke å forutsi fremtiden. Navnet på en klasse bør baseres på dens nåværende antagelser. Vi forventer ikke at en bil skal få egenskaper fra en båt. Derfor, hvis nåværende appkrav sier at det er behov for en bil, bør klassenavnet være Car i stedet for Vehicle.
Barnklasser bør navngis på samme måte. Med Car-klassen kan vi legge til en mer spesifikk versjon, for eksempel CarPickup for en spesiell type Car som har større lasteplass.
Dette innebærer at regelen om å navngi ting på ett nivå av abstraksjon høyere enn innholdet gjelder for metoder og variabler, men ikke for klasser.
Enkelt Ansvarsprinsipp
Et av SOLID prinsippene sier at hver modul eller klasse skal være ansvarlig for bare én ting. Det er ganske enkelt lettere å navngi et element som har bare én funksjon.
For eksempel, det eneste ansvaret til en flaske er å være en beholder for væsker. Vi bør ikke gi en flaske-modul muligheten til å bevege seg rundt eller gjøre andre ting som ikke er en enkel flaske sitt ansvar (i appen). Hvordan ville du navngitt en beholder for væsker som kan bevege seg?
Det er ganske vanskelig, og flaske er bare et enkelt eksempel. I stedet for å komme opp med gående (og deretter muligens dansende, løpende og snakkende) flasker, er det bedre å bruke det enkle ansvarsreglene. Lag én klasse for en væskebeholder, kall den Bottle og en annen for en bevegelig flaske, kall den BottleCarrier.
Det enkle ansvarsreglene gjelder også variabler. Hver variabel bør ha bare ett ansvar, uansett om det er en variabel i en metode, klasse eller en annen type variabel. Som med klassenavn er det bare lettere å navngi en variabel som har bare ett ansvar.
Vurder Domene Som En Sett Av Mindre Deler
God arkitektur er kombinert med gode navn. Det er lettere å navngi ting når du forstår problemene de løser. En av teknikkene som hjelper til med å bygge en bedre arkitektur, er å dele hver del av oppgaven din inn i små biter. Det vil gjøre navngivningen raskere og enklere.
Bare tenk på det, er det ikke bedre å gi navn til moduler eller objekter når du vet hva deres formål er? La oss si at vi må beskrive en bil. Det er vanskelig å navngi hver funksjonalitet i én klasse, men hvis vi deler det opp i mange mindre deler, viser det seg at vi kan lage Wheel, Tire, steeringWheel klasser sammen med andre klasser dedikert til alle andre deler som en bil kan inneholde. Disse mindre komponentene er enkle å navngi, og deres formål er enkle å spesifisere. Derfor, hvis komponentene dine er vanskelige å navngi, kan det bety at du har noen problemer med app-arkitekturen.
Oppsummering
Hvert godt navn gitt til en variabel, metode, objekt eller klasse, vil lønne seg, før eller senere. I min artikkel viste jeg noen enkle teknikker som vil hjelpe deg med å gi gode navn:
- Gå ett nivå av abstraksjon høyere enn kroppen (alle unntatt klassenavn)
- Navnet bør beskrive klassens ansvar
- Respekter enkeltansvar (ett av SOLID-reglene)
- Del problemer opp i mindre biter
God navngivning trenger ikke å være vanskelig. Det er virkelig verdt det å bruke litt tid på å navngi ting på riktig måte. Ved å bruke tipsene nevnt ovenfor, vil det gjøre den prosessen raskere.
Denne artikkelen ble inspirert av boken “99 Bottles of OOP”, skrevet av Sandi Metz & Katrina Owen. Jeg oppfordrer deg til å lese den. I tillegg til hvordan man navngir ting, vil du lære om gode praksiser for kodeomstrukturering.
