Kotlin Android fejlesztőknek: Adatosztály

az adatosztály olyan fogalom, amely nem kötődik semmilyen konkrét programozási nyelvhez, ez egy olyan minta, amely elég kényelmes a legtöbb programozó számára, mint egyszerű módja az információk ábrázolásának, beágyazásának és mozgatásának.

az adatosztály olyan osztályra utal, amely csak mezőket és crud metódusokat tartalmaz az azokhoz való hozzáféréshez (getterek és beállítók). Ezek egyszerűen tárolók más osztályok által használt adatokhoz. Ezek az osztályok nem tartalmaznak további funkciókat, és nem tudnak önállóan működni a saját adataikon.

az adatosztályok általában valós entitásokat képviselnek, és gyakori, hogy több tucat vagy száz ilyen osztály van egy projektben, ami azt jelenti, hogy ezeknek az objektumoknak a létrehozása, módosítása és manipulálása nagyon gyakori feladat a fejlesztő számára.

Adatosztály a Java-ban

így néz ki általában egy adatosztály a Java-ban:

észre fogod venni, hogy felülírjuk a toString(), equals() és hashCode() módszereket (a Object.java osztályban deklarálva ). Miért fontos ezeknek a módszereknek a felülbírálása az adatosztályokban?

e három módszer megvalósításakor értékobjektumokat hozunk létre, olyan osztályokat, amelyeknél bármely két, megfelelően azonos mezőértékkel rendelkező példány felcserélhetőnek tekinthető. (Megjegyzés: ahhoz, hogy teljesen igaz legyen, meg kell változtatnunk az osztályt. A mezők véglegesítése és a szetterek eltávolítása segít. A változhatatlanságot gyakran jó gyakorlatnak tekintik, és lehetőség szerint ajánlják)

• equals() : alapértelmezés szerint true értéket ad vissza, csak akkor, ha a két változó ugyanarra az objektumra vonatkozik, azaz ha a memóriában lévő pozíció azonos. Felülbíráljuk ezt a módszert a true visszaadására, ha az objektumok ugyanazt az információt tartalmazzák, más szóval, ha az objektumok ugyanazt az entitást képviselik. Ellenőrzi, hogy a tulajdonságok azonosak – e, és ugyanazt az értéket tartalmazzák-e.
• hashCode() : alapértelmezés szerint hexadecimálisan adja vissza az objektum memóriacímét. Ez egy numerikus érték egy objektum azonosítására az egyenlőség tesztelése során, azaz az egyenlő objektumok azonos hash kóddal rendelkeznek. Ezt a módszert felül kell írni, ha a toString() felül van írva, így a tulajdonságok értékeiből számított hash kódot ad vissza.
• toString(): Alapértelmezés szerint az objektum típusát és a hashCode() értéket adja vissza, például [email protected]+. Mi felülbírálja ezt a módszert, amelynek egy ember által olvasható változata az objektum, mint a User(name=Steve, surname=Jobs).

annak ellenére, hogy ilyen fontos fogalom, a fenti Java kódban semmi sem különbözteti meg ezt az osztályt a többitől. A programozók felismerhetik adatosztályként az osztály szerkezete és mintái miatt, de a fordító szempontjából ez az osztály csak egy másik osztály.

az adatosztályok létrehozása olyan gyakori, hogy a fejlesztők gyakran használják az IDE-t és más plugineket, hogy segítsenek nekik ebben az ismétlődő feladatban. Az adatosztály Java-ban történő létrehozásának fájdalmát enyhíthetik a bővítmények vagy az IDE, de a legtöbb hibát ezen osztályok további módosításaival vezetik be. Nagyon könnyű elfelejteni, hogy módosítsa az összes Társ módszerek Ennek megfelelően minden alkalommal, amikor egy mező ez eltávolított vagy hozzáadott.

a Java adatosztályának nincs nyelvi támogatása. Ez egy ismétlődő és hibára hajlamos feladat, amely túl sok súrlódást jelent egy modern programozási nyelv számára.

egy adatosztály Kotlinben

ugyanez az adatosztály Kotlinben valahogy így nézne ki:

data class User(var name: String, var age: Int)

Kotlin emeli az adatosztályokat az első osztályú polgárok számára, bemutatva a data kulcsszót. Bontsuk le.

• Getterek és szetterek

a getterek és szetterek automatikusan létrejönnek Kotlinben, amikor tulajdonságokat deklarálunk. Röviden, a var name: String azt jelenti, hogy a User osztálynak van egy tulajdonsága, amely nyilvános (Kotlin alapértelmezett láthatósága), változtatható (var) és String típusú. Mivel ez nyilvános, létrehozza a gettert, és mivel változtatható, létrehozza a szettert.

ha azt akarjuk, hogy az osztály csak olvasható legyen (nincs beállító), akkor a következőket kell használnunk val :

data class User(val name: String, val age: Int)

a val és var azonos osztálydeklarációban keverhetők. A val egy final változónak tekinthető a Java-ban.

minden eddig elmagyarázott, ez a Kotlin bármely osztálydeklarációjára jellemző, de a data kulcsszó az, ami itt különbséget tesz.

• a datakulcsszó

deklarálása egy osztály, mint egy adat osztály fog minket végre toString(), hashCode() és equals() automatikusan ugyanúgy, ahogy fentebb leírtuk a Java osztály. Tehát, ha létrehozunk egy felhasználói osztályt, mint a User("Steve Jobs",56) és meghívjuk a toString() metódust, akkor valami ilyesmit kapunk:User(name=Steve Jobs, age=56).

Destrukturáló deklarációk

a data kulcsszó olyan funkciókat biztosít, amelyek lehetővé teszik a destrukturáló deklarációkat. Röviden, ez létrehoz egy funkciót minden tulajdonság, így meg tudjuk csinálni a dolgokat, mint ez:

Copy function

a data kulcsszó ad nekünk egy praktikus módja a másolás osztályok értékének megváltoztatásával egyes tulajdonságok. Ha azt akarjuk, hogy hozzon létre egy példányt a felhasználó megváltoztatja a kor, ez az út tennénk:

az osztálytestben deklarált tulajdonságok figyelmen kívül maradnak

a fordító csak az elsődleges konstruktorban definiált tulajdonságokat használja az automatikusan generált függvényekhez.

a tulajdonság address nem fogja kezelni a data kulcsszóval, tehát ez azt jelenti, hogy az automatikusan generált megvalósítások figyelmen kívül hagyják.

Pair and Triple

Pair és Triple standard adatosztályok a könyvtárban, de a Kotin dokumentumok maguk is megakadályozzák azok használatát az olvashatóbb és személyre szabottabb adatosztályok javára.

követelmények és korlátozások

• egy adatosztály-konstruktornak legalább egy paraméterrel kell rendelkeznie.
• minden paraméternek val vagy var néven kell lennie .
• egy adatosztály nem lehet abstract, open, sealed vagy inner.
• equals , toString a hashCode metódusok pedig kifejezetten felülírhatók.
• Explicit implementációk a componentN() és copy() függvényekhez nem engedélyezettek.
• adatosztály levezetése egy copy() függvénymegfelelő aláírással rendelkező típusból a Kotlin 1.2-ben elavult, a Kotlin 1.3-ban pedig tilos volt.
• a data osztály nem terjedhet ki egy másik data osztályból.
• a data osztály kiterjesztheti más osztályok (mivel Kotlin 1.1)

az Adatosztályok Kotlin első osztályú állampolgárai. Nagyon rövid szintaxissal súrlódásmentes megoldást kínálnak minden előnnyel és kompromisszumok nélkül.

mit jelent az Android számára

megpróbálom elmagyarázni, hogy melyek a fő előnyök, amelyeket a Kotlin adatosztályok használatával találtam az Android projektjeimben. Ezek nem mind, és talán nem is a legfontosabbak, de az eddigi tapasztalataim alapján ezek a legnyilvánvalóbbak.

• adatmodellek

az Android architektúrája forró téma volt (és még mindig). Számos lehetőség létezik, de a legtöbbben közös az aggodalmak szétválasztása és az egységes felelősség elve. Clean Architecture-nagyon híres az Android közösség-egy sor jó gyakorlatok követni, ha célja a jó építészet, amely hangsúlyt fektet a különböző modellek különböző rétegeiben az építészet. Ez azt jelenti, hogy egy 3 vagy 4 különböző adatmodellel rendelkező projekt szabványossá válik.

ez azt jelenti, hogy a projekt adatosztályainak száma nagyon magas, és az olyan műveletek, mint a létrehozás, olvasás, módosítás, másolás, összehasonlítás, térkép… az adatmodell osztályok napi feladatok, amelyek részesülnek a Kotin Adatosztály automatikusan generált kódjából. Rengeteg időt takarít meg, és csökkenti a hibák bevezetésének lehetőségeit.

• nincs több Automatikus érték

az értéktípusok használata jó gyakorlat az Androidban, különösen az adatosztályok között.

az értéktípus egy megváltoztathatatlan értékosztályból származó objektum.
az értékosztály olyan osztály, amelynek egyenlősége a tartalmától függ.
a megváltoztathatatlan osztály olyan osztály, amelyet a létrehozás után nem lehet módosítani.

az AutoValue egy népszerű könyvtár a Google-tól, amely segít értéktípusok létrehozásában. Ez teszi a dolgát, de ez nagyon bőbeszédű valamit, ami nem lehet olyan bonyolult.

a kotlin data osztályok használata a val hozzáférési módosítóval elég közelítést ad az értéktípusokhoz.

data class User(val name : String, val age : Int)

az előző felhasználói osztály egy olyan osztály, amely elég közel áll az értéktípusokhoz, sokkal rövidebb szintaxissal. Egy jó darab ember számára az AutoValue helyettesíthető Kotlinnel. Kevesebb kód, nincs kommentárfeldolgozás, és eggyel kevesebb könyvtár függ.

Megjegyzés: Kotlin csak olvasható tulajdonságokat és osztályokat kínál a val kulcsszóval. A csak olvasható és megváltoztathatatlan nem ugyanaz (többet itt), de általában elég jónak tekinthető gyakorlati célokra.

• No more Lombok

az egyik módja annak, hogy a fejlesztők időt takarítsanak meg az adatosztályok kezelése során, a könyvtárak használata getter és setter módszerek létrehozására. Lombok az egyik (in)híres az Android/Java-ban. Ehhez nem csak a könyvtár, hanem egy plugin AS. A hosszú történet rövid a legtöbb fejlesztő Lombok hogy annyi előnye van, mint a fejfájás, így válik, hogy a könyvtár elkezd szeretni, de egy idő után, nem lehet várni, hogy megszabaduljon, de soha nem, mert mindenhol.

tekintettel arra, hogy a Kotlin Adatosztályoknak nem kell manuálisan írniuk getter/szetter módszereket, a Lombok fő igénye megszűnt.

• RecyclerView DiffUtil

RecyclerView Android a widget. Minden alkalmazásban több képernyőn van. Az újrahasznosítás egyik fontos elemea nézet adapterek a DiffUtil osztály. A DiffUtil kiszámítja a két lista közötti különbséget annak érdekében, hogy a módosításokat-ha vannak – elküldje az adapternek. Sokkal hatékonyabb, mint az egész lista újra és újra frissítése, és gyönyörűen animálja a változásokat.

a DiffUtil nagymértékben támaszkodik az elemek egyenlőségére, vagyis két elem azonos, ha tartalmuk azonos. Minden alkalommal, amikor RecyclerView-t használ, a DiffUtil-t kell használnia, ami azt jelenti, hogy összehasonlításra van szüksége, ha két objektum ugyanazt az információt tartalmazza. Ez az egyik oka annak, hogy felül kell írnunk a equals értéket a Java adatosztályainkban, de a Kotlin data osztályokkal ingyen jön.

Megjegyzés: Ha nem ismeri a DiffUtil-t, ellenőrizze ezt a gyors üzembe helyezési útmutatót.

• tesztek

a tesztosztályokban folyamatosan ellenőrizzük, hogy a várt értékek megegyeznek-e a tényleges értékekkel. Az objektumok egyenlőségének összehasonlítása (a korábban leírtak szerint) nagyon gyakori feladat.

még akkor is, ha nem kell felülírnia a equals, toString és toHash triplett az Ön rendszeres app runtime, az esélye, hogy lesz szüksége, hogy felülírja ezeket a módszereket tesztelési célokra nagy, így Kotlin adatosztályok törölje az utat a tesztelés nincs kifogás.

kiegészítés

beszéljünk néhány más gyakori forgatókönyvről, amelyeket érdemes megemlíteni, amikor Kotlin adatosztályokkal dolgozunk. Ez nem szigorúan kapcsolódik az adatosztályokhoz, de különösen gyakori közöttük.

• több konstruktor

data class User(val name : String, val age : Int)

a korábban definiált User osztályban explicit módon meg kell adnunk a name és age értékeket, amikor létrehozunk egy olyan példányt, mint a User("Steve", 56) .

Kotlinben definiálhatjuk az argumentumok alapértelmezett értékeit oly módon, hogy abban az esetben, ha nem adjuk át az argumentum értékét, az alapértelmezett értéket rendeljük hozzá.

data class User(val name : String, val age :Int = 0)

User("Steve", 56) továbbra is érvényes, de most egy második konstruktor User("Steve") megengedett. Ebben az esetben a age érték 0 lesz.

alapértelmezett értékeket rendelhetünk mindkét paraméterhez, lehetővé téve a User() harmadik konstruktort, ahol az name üres lesz, a age pedig 0 lesz.

data class User(val name : String = "", val age : Int = 0)

tehát most User(), User("Steve") és User("Steve",56) mind érvényes hívások.

ennek vannak korlátai: Az opcionális paramétereknek a konstruktor utolsó paramétereinek kell lenniük. A következő nem fog összeállni.

data class User(val name : String = "", val age : Int)
val user = User(56) // This doesn't compile

további korlátozás, hogy ha több opcionális paraméterünk van, azokat jobbról balra kell kihagyni.

data class User(
val name : String,
val surname : String = "",
val age : Int = 0
)User("Steve")
User("Steve", "Jobs")
User("Steve", "Jobs", 56)
User("Steve",56) // This wont compile

ennek a korlátozásnak a kezelésére Kotlin nevesített argumentumokat kínál. Ez lehetővé teszi számunkra, hogy meghatározzuk, melyik argumentum tartozik minden értékhez. Most olyan dolgokat tehetünk, mintUser(name = "Steve", age = 56) — vagy rövidebb User("Steve", age = 56) – ahol a vezetéknév Az alapértelmezett értékhez lesz rendelve.

Az alapértelmezett argumentumok és a megnevezett argumentumok nagyon hasznos módja annak, hogy több konstruktort és túlterhelést kínáljunk egy nagyon kompakt deklarációból.

• @JvmOverloads

az előző pontban leírtak nem veszik figyelembe a Java oldalról érkező hívásokat. Kotlin interoperábilis a Java-val, így képesnek kell lennünk a User osztály példányainak létrehozására Java-ból.

ha nem fogja használni a Java-ból, akkor kész, de egyébként szüksége lesz a @JvmOverloads kommentárra, mivel a Java nem kínál megnevezett argumentumokat.

data class User @JvmOverloads constructor(
val name : String,
val surname : String = "",
val age : Int = 0
)

mi ez csinál generáló több konstruktorok, így lehet nevezni a Java.

MEGJEGYZÉS: fontos megjegyezni, hogy nem minden lehetséges permutációt fog létrehozni, hanem azokat, amelyek az opcionális argumentumok jobbról balra történő eltávolításából származnak. Bővebben itt

• Builders

mivel Kotlin ajánlatok megnevezett paraméterek és alapértelmezett argumentumok, ez teszi kevésbé valószínű, hogy szükség van építők. Ráadásul a modern IDE-k, mint például az Android Studio, már megmutatják a paraméter nevét a hívó oldalon, megkönnyítve az olvasást, így kevésbé érdekes csak olvashatóság céljából.

azokban az esetekben, amikor az építőminta még mindig szükséges. Kotlin nem kínál semmi különlegeset, hogy segítsen nekünk. A Kotlin építőmintája így néz ki:

• Megjegyzések

nagyon gyakori, hogy egyes adatmodell osztályok annotációs feldolgozást használnak. Például API modellek (adatosztályok az API dezerializált válaszainak ábrázolására) gyakran jegyzetekkel vannak ellátva Gson vagy Moshi kommentárok. A perzisztencia modellek (a helyi tárolóban/adatbázisokban tárolt adatok ábrázolására szolgáló adatosztályok) gyakran szobai vagy birodalmi jegyzetekkel vannak ellátva.

Kotlinban még mindig használhatjuk ezeket a kommentárokat. Például, ez egy felhasználói modell, amelyet a szoba adatbázisában kell tárolni:

Összegzés

Kotlin adat osztályok az eredménye éves tanulás fájdalom és frusztráció adat osztályok Java. Arra törekszenek, hogy minden előnyük legyen, és ne legyenek hátrányai. Használata nagyon egyszerű és élvezetes, és ha egyszer megszokja, nagyon nehéz visszanézni.

az Androidban különböző módon segítenek nekünk, de többnyire sok időt takarítanak meg és csökkentik a hibákat.

a Kotlin adatosztály jó példa arra, hogy mi a Kotlin programozási nyelv: tömör, pragmatikus és öröm a fejlesztők számára.