Kotlin For Android-Utviklere: Dataklasse | JMX Trans
Kotlin For Android-Utviklere: Dataklasse
en dataklasse er et konsept som ikke er knyttet til et bestemt programmeringsspråk, det er et mønster som er praktisk nok til de fleste programmerere som en enkel måte å representere, kapsle og flytte informasjon rundt.
en dataklasse refererer til en klasse som bare inneholder felt og crud-metoder for tilgang til dem(getters og settere). Dette er bare beholdere for data som brukes av andre klasser. Disse klassene inneholder ingen ekstra funksjonalitet og kan ikke operere uavhengig av dataene de eier.
vanligvis representerer dataklasser virkelige enheter, og det er vanlig å ha dusinvis eller hundrevis av disse klassene i et prosjekt, noe som betyr at det å skape, endre og manipulere disse objektene er en veldig vanlig oppgave for en utvikler.
Par og Trippel
Hva betyr Det For Android
slik ser en dataklasse vanligvis ut I Java:
Du vil legge merke til at vi overstyrer toString() , equals() og hashCode() metoder (deklarert i Object.java – klassen ). Hvorfor er overstyring av disse metodene relevante i dataklasser?
når vi implementerer disse tre metodene, oppretter vi verdiobjekter, klasser hvor to forekomster med passende like feltverdier anses utskiftbare. (Merk: For å være helt sant, må vi gjøre klassen uforanderlig. Å gjøre feltene endelige og fjerne settere hjelper. Uforanderlighet anses ofte som en god praksis og anbefales når det er mulig)
equals() : som standard returnerer true bare hvis de to variablene refererer til samme objekt, dvs. hvis posisjonen i minnet er den samme. Vi overstyrer denne metoden for å returnere true hvis objektene inneholder samme informasjon, med andre ord hvis objektene representerer samme enhet. Det sjekker egenskapene er de samme og de inneholder samme verdi.
hashCode() : som standard returnerer objektets minneadresse i heksadesimal. Det er en numerisk verdi for å identifisere et objekt under likhetstesting, dvs. like objekter har samme hash-kode. Denne metoden må overstyres når toString() overstyres, slik at den returnerer en hash-kode beregnet ut fra verdiene til egenskapene.
toString(): Som standard returnerer objekttypen og hashCode(), for eksempel [email protected]+. Vi overstyrer denne metoden for å ha en mer lesbar versjon av objektet som User(name=Steve, surname=Jobs).
Til tross for å være et så viktig konsept, er det ingenting i Java-koden ovenfor som gjør denne klassen forskjellig fra noen andre. Programmerere kan gjenkjenne det som en dataklasse på grunn av klassestrukturen og mønstrene, men fra kompilatorens synspunkt er denne klassen bare en annen klasse.
Å Lage dataklasser Er så vanlig at utviklere ofte bruker IDE og andre plugins for å hjelpe dem med denne repeterende oppgaven. Smerten ved å lage en dataklasse I Java kan lindres av plugins eller IDE, men de fleste bugs blir introdusert på ytterligere modifikasjoner av disse klassene. Det er veldig lett å glemme å endre alle følges metoder tilsvarende hver gang et felt det er fjernet eller lagt.
en dataklasse i Java mangler språkstøtte. Det er en repeterende og bug-utsatt oppgave som representerer for mye friksjon for et moderne programmeringsspråk.
den samme dataklassen I Kotlin ville se slik ut:
Kotlin hever dataklasser til førsteklasses borgere innføre data søkeord. La oss bryte det ned.
Getters and settere
getters and settere opprettes automatisk i Kotlin når vi deklarerer egenskaper. Kort sagt, hva var name: String betyr er at klassen User har en egenskap som er offentlig (standard synlighet I Kotlin), foranderlig (var) og er en String type. Gitt det er offentlig det skaper getter, og gitt det er foranderlig det skaper setter.
hvis vi vil gjøre klassen skrivebeskyttet( ingen settere), må vi bruke val :
vi kan blande val og var i samme klassedeklarasjon. Du kan tenke på val som en final variabel I Java.
Alt forklart så langt, det er vanlig for enhver klassedeklarasjon I Kotlin ,men data søkeordet er det som gjør en forskjell her.
data søkeordet
Deklarering av en klasse som dataklasse vil få oss implementert toString(), hashCode() og equals() automatisk på samme måte som vi beskrev ovenfor for Java-klassen. Så hvis vi lager en brukerklasse som User("Steve Jobs",56) og kaller toString() – metoden, får vi noe som:User(name=Steve Jobs, age=56) .
nøkkelordet data inneholder funksjoner som tillater destruktureringsdeklarasjoner. Kort sagt, det skaper en funksjon for hver eiendom, slik at vi kan gjøre ting som dette:
nøkkelordet data gir oss en praktisk måte å kopiere klasser som endrer verdien av noen egenskaper. Hvis vi ønsker å lage en kopi av en bruker endre alder, dette er måten vi ville gjøre det:
Egenskaper deklarert i klassekroppen ignoreres
kompilatoren bruker bare egenskapene definert i primærkonstruktøren for de automatisk genererte funksjonene.
egenskapen address det kommer ikke til å bli behandlet av nøkkelordet data, så det betyr at de automatisk genererte implementeringene vil ignorere det.
Pair og Triple er standard dataklasser i biblioteket, Men Kotin-dokumentene fraråder bruken av Dem til fordel for mer lesbare og skreddersydde dataklasser.
en dataklassekonstruktør må ha minst en parameter.
alle parametere må være markeds som val eller var.
en dataklasse kan ikke abstract, open, sealed eller inner.
equals , toString og hashCode metoder kan eksplisitt overstyres.
Eksplisitte implementeringer for componentN() og copy() funksjoner er ikke tillatt.
Utlede en dataklasse fra en type med en copy() funksjon matchende signatur ble avviklet I Kotlin 1.2 og ble forbudt I Kotlin 1.3.
en data – klasse kan ikke strekke seg fra en annen data – klasse.
a data klasse kan utvide andre klasser (siden Kotlin 1.1)
dataklasser er førsteklasses borgere i Kotlin. I en veldig kort syntaks tilbyr de en friksjonsløs løsning med alle fordelene og ingen kompromisser.
jeg skal prøve å forklare hva som er de viktigste fordelene jeg har funnet ved Å bruke Kotlin dataklasser I Mine Android-prosjekter. Disse er ikke alle av dem, og kan ikke være de viktigste, men disse er de mest åpenbare fra min erfaring så langt.
Arkitektur I Android var (og er fortsatt) et hett tema. Det finnes flere alternativer, men de fleste av dem har til felles separasjon av bekymringer og enkelt ansvar prinsipper. Ren Arkitektur-veldig kjent I Android-samfunnet – er et sett med god praksis å følge når du sikter på en god arkitektur som legger vekt på å bruke ulike modeller for ulike lag av arkitekturen. Dette betyr at et prosjekt med 3 eller 4 forskjellige datamodeller blir standard.
det betyr At antall dataklasser i et prosjekt er svært høyt, og operasjoner som opprett, les, endre, kopiere, sammenligne, kartlegge… datamodellklasser er daglige oppgaver som drar nytte Av Kotin-Dataklassen automatisk generert kode. Sparer mye tid og reduserer mulighetene for å introdusere feil.
Ingen Flere Auto-Verdi
Bruk av verdityper er en god praksis som er svært utvidet I Android, spesielt blant dataklasser.
en verditype er et objekt fra en uforanderlig verdiklasse.
en verdiklasse er en klasse hvor likestilling avhenger av innholdet.
en uforanderlig klasse er en klasse som ikke kan endres etter opprettelsen.
AutoValue Er et populært bibliotek Fra Google som hjelper Oss med å skape verdityper. Det gjør jobben sin, men det er veldig verbose for noe som ikke burde være så komplisert.
ved hjelp av kotlin data – klassene med val tilgangsmodifikatoren gir vi en nær nok tilnærming til verdityper.
den forrige brukerklassen er en klasse nær nok til verdityper, i en mye kortere syntaks. For en god del av mennesker Kan AutoValue erstattes Av Kotlin. Mindre kode, ingen annotasjonsbehandling, og ett mindre bibliotek å stole på.
Merk: Kotlin tilbyr skrivebeskyttede egenskaper og klasser med nøkkelordet val. Skrivebeskyttet og uforanderlig er ikke det samme (mer her), men generelt anses det som godt nok til praktiske formål.
Ikke Mer Lombok
en av måtene utviklere prøvde å spare tid på når de håndterer dataklasser, bruker biblioteker til å generere getter og setter-metoder. Lombok er en Av De (i)kjente seg I Android / Java. Det krever ikke bare biblioteket, men også en plugin FOR AS. Den lange historien kort er For De fleste utviklere Lombok bringe så mange fordeler som hodepine, så det blir at biblioteket du begynner å elske, men etter en stund, du kan ikke vente med å bli kvitt, men du aldri gjøre fordi er overalt.
Gitt At Kotlin – Dataklasser ikke krever å skrive getter/setter-metoder manuelt, er hovedbehovet for Lombok borte.
RecyclerView I Android er widgeten. Det er i hver app i flere skjermer. En viktig komponent ved implementering Av RecyclerView-adaptere er DiffUtil-klassen. DiffUtil beregner diff mellom to lister for å sende endringene – hvis noen – til adapteren. Det er mye mer effektivt enn å oppdatere hele listen igjen og igjen, og det animerer endringene vakkert.
DiffUtil er avhengig av elementenes likestilling, noe som betyr at to elementer er de samme når innholdet er det samme. Hver Gang Du bruker En RecyclerView, bør Du bruke DiffUtil, noe som betyr at du trenger en måte å sammenligne om to objekter inneholder samme informasjon. Dette er en av grunnene til at vi må overstyre equals i Våre Java-dataklasser, men Med Kotlin data – klasser kommer det gratis.
Merk: hvis Du ikke er kjent Med DiffUtil, sjekk denne hurtigstartveiledningen.
i testklasser sjekker vi hele tiden om de forventede verdiene samsvarer med de faktiske verdiene. Sammenligning av objekter likestilling (som beskrevet tidligere) er en svært vanlig oppgave.
selv om du ikke trenger å overstyre equals , toString og toHash triplet for deg vanlig app runtime, er sjansene for at du må overstyre disse metodene for testformål høye, Så Kotlin – dataklasser fjerner banen til testing uten unnskyldninger.
la oss snakke om noen andre vanlige scenarier som er verdt å nevne når du arbeider med Kotlin-dataklasser. Dette er ikke strengt knyttet til dataklasser, men er spesielt vanlig blant dem.
i User – klassen vi definerte tidligere, må vi eksplisitt spesifisere name og age når du oppretter en forekomst som User("Steve", 56).
I Kotlin kan vi definere standardverdier for argumenter på en slik måte at hvis vi ikke sender en verdi for det argumentet, blir standardverdien tildelt den.
User("Steve", 56) er fortsatt gyldig, men nå er en andre konstruktør User("Steve") tillatt. I så fall vil verdien age være 0.
vi kan tildele standardverdier til begge parametrene slik at en tredje konstruktør User() der name vil være tom og age vil være 0.
så nå User(), User("Steve") og User("Steve",56) alle er gyldige samtaler.
Dette har noen begrensninger: Valgfrie parametere må være siste parametere i konstruktøren. Den neste vil ikke kompilere.
En annen begrensning er at hvis vi har flere valgfrie parametere, må de hoppes over fra høyre til venstre.
For å håndtere disse begrensningene Tilbyr Kotlin navngitte argumenter. Dette gjør at vi kan spesifisere hvilket argument som tilhører hver verdi. Nå kan vi gjøre ting somUser(name = "Steve", age = 56) – eller kortere User("Steve", age = 56) – der etternavnet vil bli tildelt standardverdien.
Standardargumenter og navngitte argumenter er en veldig praktisk måte å tilby flere konstruktører og overbelastninger fra en svært kompakt erklæring.
alt forklart i forrige punkt tar ikke hensyn til anrop fra Java-siden. Kotlin er interoperabel Med Java, så vi må kunne lage forekomster av User – klassen Fra Java.
Hvis du ikke skal bruke Den Fra Java, er du ferdig, men ellers trenger du @JvmOverloads annotasjonen gitt At Java ikke tilbyr navngitte argumenter.
hva dette gjør genererer flere konstruktører slik at Det kan kalles Fra Java.
Merk: Det er viktig å legge merke til at det ikke kommer til å skape alle mulige permutasjoner, men de som følge av å fjerne de valgfrie argumentene fra høyre til venstre. Mer her
Gitt Kotlin tilbyr navngitte parametere og standardargumenter, gjør det det mindre sannsynlig behovet for byggere. På toppen av det viser moderne Ideer som Android Studio allerede navnet på parameteren på anropssiden, noe som gjør det lettere å lese, noe som gjør det mindre interessant bare for lesbarhetsformål.
i tilfeller der byggemønsteret fortsatt er nødvendig. Kotlin tilbyr ikke noe spesielt for å hjelpe oss med det. Et byggemønster i Kotlin ser ut som:
det er svært vanlig at enkelte datamodellklasser bruker merknadsbehandling. FOR EKSEMPEL API-Modeller (dataklasser for å representere deserialiserte svar fra API) blir ofte annotert Med gson-eller Moshi-merknader. Persistence-modellene (dataklasser for å representere data lagret i lokal lagring/databaser) blir ofte annotert Med Rom-eller Realm-annoteringer.
I Kotlin kan vi fortsatt bruke disse merknadene. For eksempel er Dette En brukermodell som skal lagres I Romdatabasen:
Kotlin dataklasser er resultatet Av mange års læring fra smerte og frustrasjon med dataklasser I Java. De tar sikte på å ha alle fordelene og ingen av ulempene. Å bruke dem er veldig enkelt og morsomt, og når du blir vant til det, er det veldig vanskelig å se tilbake.
I Android hjelper De oss på forskjellige måter, men for det meste sparer de mye tid og reduserer feil.
En Kotlin – dataklasse er et godt eksempel på Hva Kotlin er som programmeringsspråk: konsis, pragmatisk og en glede for utviklere.