Ruby tarkvara arendamine: Pangameetodid ja nende loomise viisid

Me võime sageli kohata väidet, et paukmeetod on teatud mõttes ohtlik meetod ja hüüumärk selle määratluse lõpus ütleb meile, et selle meetodi kasutamisel tuleb olla valvas. Vaatame: mis on see ohtlikkus täpselt, kui tegemist on nende meetoditega ja millised on nende omadused?

Paukmeetodite omadused

1. Põrgumeetod muudab vastuvõtjat

Selliste meetodite üks populaarsemaid omadusi on see, et nad tavaliselt muudavad oma publikut. Võtame näitena map! meetodi. Dokumentatsiooni kohaselt kutsub map! meetod antud plokki üks kord iga self'i elemendi kohta, asendades elemendi ploki poolt tagastatud väärtusega ja kui plokki ei ole antud, tagastatakse selle asemel Enumerator.

 arry = [1, 2, 3, 4, 5]
 arry.object_id => 280
 arry.map! {|num| num**num } => [1, 4, 27, 256, 3125]
 arry.map!                       => #
 arry.map! {|n| n } => [1, 4, 27, 256, 3125]
 arry.object_id => 280

Nagu näeme, jääb object_id muutumatuks. Seega tundub sellise meetodi kasutamise oht ilmne. Kui meie kood me kasutasime muutujat arry kuskil mujal, siis kaart! muudab seda. See võib põhjustada meie programmi ebasoovitavat toimimist või isegi krahhi.

Seal on objektid Ruby mida ei saa muuta, näiteks klasside Integer, Float ja Symbol isendid. Töötamise ajal on projekt, võid ka kohtuda nn magic-kommentaariga, mis läheb nii:

frozenstringliteral: true

Püüdes muuta stringi saaja koodi, kus sellist kommentaari kasutati, tekiks selline viga:

 'abc'.upcase!
 FrozenError (ei saa muuta külmutatud stringi)

Huvitaval kombel oli kavas kehtestada muutumatu stringi sisse Ruby 3.0, kuid otsustati seda muudatust mitte teha. Siiski tuleb meeles pidada, et mitte kõik paukmeetodid ei muuda vastuvõtjat, seega tuleks alati kontrollida dokumentatsioonist, millist ohtu peaksite konkreetse meetodi puhul ootama.

2. Bangi meetod tekitab erandi

Veel üks nende meetodite eripära on see, et paljude meetodite puhul tehakse erand. Näide sellisest meetodist on ActiveRecord::FinderMethods#first! Dokumentatsiooni kohaselt on meetod first! sama, mis esimene, kuid tekitab ActiveRecord::RecordNotFound, kui kirjeid ei leita. Pange tähele, et first! ei võta vastu ühtegi argumenti.

Faili activerecord/lib/activerecord/relation/findermethods.rb, rida 128

def first!
first || raiserecordnotfoundexception!
end

Kuid ActiveRecord::FinderMethods#first meetod, mida kasutatakse eespool, näeb välja nii:

Faili activerecord/lib/activerecord/relation/findermethods.rb, rida 116

def first(limit = nil)
checkreorderdeprecation unless loaded?

if limit
findnthwithlimit(0, limit)
else
findnth 0
end
end

Tänu ülaltoodud näidetele näeme ohtu, et kasutada esimest. Kui me kasutame ActiveRecord::FinderMethods#find! ja see ei leia andmebaasist sobivat kirjet, siis tagastab ta ActiveRecord::RecordNotFound, mis võib põhjustada meie programmi töö seiskumise.

Siiski tuleb meeles pidada, et see ei tähenda, et kui meetodi lõpus ei ole hüüumärki, siis on see turvaline ja ei tekita erandit ega muuda vastuvõtjat.

Ruby on Rails 6.0 võeti kasutusele uus meetodite paar: ActiveRecord::Persistence::ClassMethods#insert_all ja ActiveRecord::Persistence::ClassMethods#insert_all!

Esimene neist meetoditest näitab juba teatavat ohtu. Noh, vastavalt dokumentatsioonile, sisestagekõik sisestab andmebaasi mitu kirjet ühe SQL INSERT-avaldusega. See ei instantseeri ühtegi mudelit ega käivita ActiveRecordi tagasikutseid ega valideerimisi. Kuid sisestamineall! tõstab lisaks ActiveRecord::RecordNotUnique, kui mõni rida rikub tabeli unikaalset indeksit. Sellisel juhul ei sisestata ühtegi rida. See tähendab, et esimene neist meetoditest salvestab kõik kirjed, välja arvatud need, mis rikuvad unikaalset indeksit, samas kui teine (ohtlikum) meetod tekitab erandi ja ei salvesta ühtegi kirjet andmebaasi.

3. Põrgumeetodil on samaväärne ilma hüüumärgita

Paljud meetodid, isegi kui nende lõpus ei ole hüüumärki, on ohtlikud kasutada. Näiteks ActiveRecord::FinderMethods#find. Vastavalt dokumentatsioonile Kui ühte või mitut kirjet ei leita taotletud id-de jaoks, siis tõstetakse ActiveRecord::RecordNotFound.

Näeme, et kuigi see meetod on sama ohtlik kui ActiveRecord::FinderMethods#first!, ei ole tal hüüumärki.

Sama kehtib ka vastuvõtja muutmise kohta. Näiteks Array.delete (nagu dokumenteeritud) kustutab kõik elemendid self'ist, mis on võrdsed objektiga, ja tagastab viimase kustutatud elemendi või nil, kui vastavaid elemente ei leita.

 a = [1, 2, 3, 4, 5]
 a.object_id #=> 320
 a.delete(2) #=> 2
 a #=> [1, 3, 4, 5]
 a.delete(6) #=> nil
 a.object_id #=> 320

On selgelt näha, et objekti on muudetud. Nende kahe meetodi ühisosa on see, et neil ei ole hüüumärgi ekvivalenti. Seega, kui meetodil, mida me soovime luua, oleks selliseid ohte, mida ma eespool mainisin, ei pea selle lõpus olema kohe hüüumärki. Lisaks on soovitatav luua paukmeetod, kui on juba olemas sama nimega meetod, mis on vähem ohtlik kui meetod, mida tahetakse luua.

Millal kasutada paukmeetodeid

Võite küsida, milleks üldse neid ohtlikke meetodeid kasutada, eriti kuna meil on tavaliselt vähem ohtlikud vasted. Üheks eeliseks võib olla näiteks koodi parem jõudlus tänu loodud objektide arvu vähendamisele. Siit saate lugeda rohkem Railsi jõudluse suurendamise kohta.

Kui tegemist on erandite tekitamisega, võib ohtliku create! asemel create meetodi kasutamine viia olukorrani, kus viga meie rakenduses on raskesti avastatav, sest kirjeid ei kirjutata andmebaasi. Seega, kui me oleme kindlad, et parameetrid, mida me sellele meetodile üle anname, on õiged, peaksime kasutama create! meetodit, mis tekitab erandi, kui mingil põhjusel ei salvestata kirjet andmebaasi.

Järeldus on lihtne ja see on järgmine: selliste meetodite mõistlik kasutamine võib parandada meie koodi jõudlust ja kvaliteeti. Siiski peame alati meeles pidama, et nende ebaõige kasutamine võib takistada koodi korralikku töötamist.

Millal luua oma paugumeetod

Kui soovite luua oma ohtliku meetodi, peate läbima teatud otsustusprotsessi. Kõigepealt tuleb küsida, kas on juba olemas meetod, millel on sama nimi kui sellel, mida soovite luua, kuid mis on vähem ohtlik. Võite kaaluda ka meetodite paari loomist, kus üks neist on samaväärne teise meetodiga, ainult ohtlikum.

Pole mõtet luua paukemeetodit, kui selle vaste ilma hüüumärgita puudub. On meetodeid, mis on ohtlikud, sest nad muudavad objekti või tekitavad erandi, aga neil ei ole nime lõpus hüüumärki. Kui luua bang-metoodika, millel puudub vaste, ajab see teie koodi kasutava programmeerija segadusse. See inimene ei oskaks öelda, milles seisneb selle meetodi ohtlikkus ja miks ta väärib hüüumärki nime lõpus.

Teiseks peaksime kaaluma, millistest ohtudest me räägime. Ülaltoodud näidetest võime järeldada, et kõige tavalisem ohu tüüp on objekti enda muutmine (selle koopia loomise asemel) või erandi tekitamine. Loomulikult ei ole see mitte reegel, vaid pigem Ruby ja Ruby on Rails-s defineeritud meetodite analüüsi tulemus. Näiteks võiksime vaadelda sellise meetodipaari rakendamist, kus meetod ilma hüüumärk salvestaks kirje andmebaasi, samas kui hüüumärgiga meetod jätaks selle kirje valideerimise vahele. Sellisel juhul on selge, milles seisneb selliste meetodite kasutamise potentsiaalne oht.

Kokkuvõte

Kokkuvõte paugumeetodite teadmistest viitab järgmistele järeldustele: 1. meetodil hüüumärgiga on vähem ähvardav vaste ilma hüüumärgita, teiseks, hüüumärgiga meetod sooritab ohtliku toimingu, nt muudab vastuvõtjat või tekitab erandi.

Kokkuvõtteks võib öelda, et mõiste bang meetodid aadressil Ruby tarkvaraarendus võib oluliselt parandada teie kodeerimisoskusi ja tuua rohkem selgust teie koodibaasi. Bang meetodid, mida tähistab hüüumärk nende nimede lõpus, näitavad meetodi destruktiivset või potentsiaalselt ohtlikku versiooni. Konventsiooni kohaselt on bang counterpart meetodi tuleks kasutada ettevaatlikult, kuna see võib muuta objekte otse, ilma eraldi koopiat loomata. See võib olla eriti kasulik, kui tegemist on muutuvate objektidega või kui tulemuslikkuse optimeerimine on probleemiks. Siiski on oluline olla ettevaatlik bang-metoodikate kasutamisel, kuna neil võivad olla soovimatud tagajärjed, kui neid ei käsitleta õigesti. Samuti tasub märkida, et mitte kõik meetodid ei ole bang versioonja nende olemasolu tuleks hinnata iga juhtumi puhul eraldi. Teades, millal ja kuidas luua bang-metoodikaid, saate seda võimsat vahendit tõhusalt kasutada ja kirjutada puhast, tõhusat koodi, mis vastab teie spetsiifilistele nõuetele.