"Ruby" programinės įrangos kūrimas: Sprogimo metodai ir jų kūrimo būdai

Dažnai galime susidurti su teiginiu, kad sprogimo metodas tam tikra prasme yra pavojingas metodas, o jo apibrėžimo pabaigoje esantis šauktukas pasako, kad tai yra pavojingas metodas. mus būti budrūs, kai naudojate šį metodą. Pažiūrėkime: kas konkrečiai yra ši grėsmė, kai kalbama apie šiuos metodus, ir kokie jų ypatumai?

Sprogimo metodų charakteristikos

1. Sprogimo metodas keičia gavėją

Viena iš populiariausių šių metodų savybių yra ta, kad jie paprastai keičia auditoriją. Kaip pavyzdį panagrinėkime metodą "Map!". Remiantis dokumentacija, metodas map! kiekvienam self elementui vieną kartą iškviečia duotą bloką, pakeisdamas elementą bloko grąžinta verte, o jei blokas nepateiktas, vietoj jo grąžinamas enumeratorius.

 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

Kaip matome, object_id išlieka nepakitęs. Taigi, tokio metodo naudojimo pavojus atrodo akivaizdus. Jei mūsų kodas naudojome kintamąjį arry bet kur kitur, tada "map!" jį pakeis. Dėl to mūsų programa gali veikti nepageidaujamu būdu arba net sugesti.

Yra objektų, esančių Ruby kurie negali būti keičiami, pavyzdžiui, Integer, Float ir Symbol klasių egzemplioriai. Dirbant su projektas, taip pat galite sutikti vadinamąjį stebuklingą komentarą, kuris skamba taip:

frozenstringliteral: true

Pabandžius pakeisti eilutės gavėją tame kode, kuriame buvo panaudotas toks komentaras, būtų gauta tokia klaida:

 'abc'.upcase!
 FrozenError (negalima keisti užšaldytos eilutės)

Įdomu tai, kad buvo planuojama įvesti nekeičiamą eilutę "Ruby 3.0, bet nuspręsta šio pakeitimo nedaryti.. Tačiau reikėtų nepamiršti, kad ne visi sprogimo metodai keičia gavėją, todėl dokumentuose visada reikėtų patikrinti, kokio pavojaus tikėtis konkretaus metodo atveju.

2. Bang metodas sukelia išimtį

Kitas išskirtinis šių metodų bruožas yra tas, kad daugeliu atveju iškeliama išimtis. Tokio metodo pavyzdys yra ActiveRecord::FinderMethods#first! Pagal dokumentaciją, metodas first! yra toks pat kaip ir first, tačiau sukelia ActiveRecord::RecordNotFound, jei nerandama jokio įrašo. Atkreipkite dėmesį, kad first! nepriima jokių argumentų.

Failas activerecord/lib/activerecord/relation/findermethods.rb, 128 eilutė

def first!
first || raiserecordnotfoundexception!
end

Tačiau ActiveRecord::FinderMethods#first metodas, kuris naudojamas pirmiau, atrodo taip:

Failas activerecord/lib/activerecord/relation/findermethods.rb, 116 eilutė

def first(limit = nil)
checkreorderdeprecation unless loaded?

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

Dėkojame už tai, kad pirmiau pateiktuose pavyzdžiuose matome, koks pavojus kyla naudojant pirmąjį variantą. Jei naudosime ActiveRecord::FinderMethods#find! ir jis neras tinkamo įrašo duomenų bazėje, tuomet bus grąžinamas ActiveRecord::RecordNotFound, dėl to mūsų programa gali nustoti veikti.

Tačiau turime atminti, kad tai nereiškia, jog jei metodo pabaigoje nėra šauktuko ženklo, jis yra saugus ir nesukels išimties arba nepakeis gavėjo.

Įvesta nauja metodų pora Ruby on Rails 6.0: ActiveRecord::Persistence::ClassMethods#insert_all ir ActiveRecord::Persistence::ClassMethods#insert_all!

Pirmasis iš šių metodų jau kelia tam tikrą pavojų. Na, remiantis dokumentais, įterptivienu SQL INSERT sakiniu į duomenų bazę įterpia kelis įrašus. Jis neįtvirtina jokių modelių ir nesukelia "ActiveRecord" iškvietimų ar patvirtinimų. Tačiau įterpimasall! papildomai sukelia ActiveRecord::RecordNotUnique, jei kuri nors eilutė pažeidžia unikalų lentelės indeksą. Tokiu atveju eilutės neįterpiamos. Tai reiškia, kad pirmasis iš šių metodų išsaugos visus įrašus, išskyrus tuos, kurie pažeidžia unikalų indeksą, o antrasis (pavojingesnis) metodas iškels išimtį ir neišsaugos nė vieno įrašo duomenų bazėje.

3. Bang metodas turi atitikmenį be šauktuko ženklo

Daugelį metodų, nors jų pabaigoje nėra šauktuko ženklo, naudoti pavojinga. Pavyzdžiui, ActiveRecord::FinderMethods#find. Pagal dokumentaciją Jei pagal prašomus id nerandama vieno ar daugiau įrašų, tada bus iškeltas ActiveRecord::RecordNotFound.

Matome, kad nors šis metodas yra tokio pat pavojingumo kaip ir ActiveRecord::FinderMethods#first!, jis neturi šauktuko ženklo.

Tas pats pasakytina ir apie gavėjo keitimą. Pavyzdžiui, Array.delete (kaip aprašyta dokumentuose) ištrina visus self elementus, kurie yra lygūs object, ir grąžina paskutinį ištrintą elementą arba nil, jei nerandama tinkamų elementų.

 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

Aiškiai matote, kad objektas buvo pakeistas. Šiems dviem metodams bendra tai, kad jie neturi šauktuko atitikmens. Todėl, jei metodas, kurį norime sukurti, turėtų tokius pavojus, kokius minėjau pirmiau, jam nereikia iš karto turėti šauktuko pabaigoje. Be to, patartina kurti šauktuko metodą, jei jau yra to paties pavadinimo metodas, kuris yra mažiau pavojingas už norimą sukurti metodą.

Kada naudoti sprogimo metodus

Galite susimąstyti, kodėl apskritai reikia naudoti šiuos pavojingus metodus, juolab kad paprastai turime mažiau pavojingų analogų. Vienas iš privalumų gali būti, pavyzdžiui, didesnis kodo našumas, nes sumažėja sukuriamų objektų skaičius. Čia galite perskaityti daugiau apie "Rails" našumo didinimą.

Kai kalbama apie išimčių kėlimą, naudojant create metodą, o ne pavojingą create!, gali susiklostyti situacija, kai klaidą mūsų programoje bus sunku aptikti, nes įrašai nebus įrašyti į duomenų bazę. Taigi, jei esame tikri, kad šiam metodui perduodami parametrai yra teisingi, turėtume naudoti metodą create!, kuris iškels išimtį, jei dėl kokių nors priežasčių įrašas nebus įrašytas į duomenų bazę.

Išvada paprasta: protingas tokių metodų naudojimas gali pagerinti mūsų kodo našumą ir kokybę. Tačiau visada turime prisiminti, kad netinkamas jų naudojimas gali sustabdyti tinkamą kodo veikimą.

Kada kurti savo sprogimo metodą

Jei norite sukurti savo pavojingą metodą, turite pereiti tam tikrą sprendimų priėmimo procesą. Pirmiausia reikia atsakyti į klausimą, ar jau yra metodas tokiu pačiu pavadinimu, kaip ir jūsų norimas sukurti metodas, tačiau ne toks pavojingas. Taip pat galite apsvarstyti galimybę sukurti metodų porą, kurioje vienas iš jų būtų lygiavertis kitam, tik pavojingesnis.

Nėra prasmės kurti metodą "Bang", jei jo atitikmuo be šauktuko ženklo neegzistuoja. Yra metodų, kurie yra pavojingi, nes keičia objektą arba sukelia išimtį, tačiau jų pavadinimo pabaigoje nėra šauktuko ženklo. Sukūrus sprogimo metodą, neturintį atitikmens, jūsų kodą naudojantis programuotojas būtų suklaidintas. Šis negalėtų pasakyti, kuo pavojingas šis metodas ir kodėl jis nusipelno šauktuko vardo pabaigoje.

Antra, turėtume apsvarstyti, apie kokius pavojus kalbame. Iš anksčiau pateiktų pavyzdžių galime daryti išvadą, kad dažniausiai pasitaikantis pavojaus tipas yra paties objekto pakeitimas (užuot sukūrus jo kopiją) arba išimties iškėlimas. Žinoma, tai nėra taisyklė, o greičiau rezultatas, gautas išanalizavus metodus, kurie buvo apibrėžti "Ruby" ir "Ruby on Bėgiai. Pavyzdžiui, galime svarstyti metodų poros įgyvendinimą, kai metodas be šauktukas išsaugotų įrašą duomenų bazėje, o metodas su šauktuku praleistų šio įrašo patvirtinimą. Šiuo atveju aišku, kur slypi galimas tokių metodų naudojimo pavojus.

Santrauka

Apibendrinus žinias apie sprogimo metodus, galima daryti šias išvadas: 1-asis metodas su šauktuku turi mažiau grėsmingas antrasis metodas su šauktuku atlieka pavojingą veiksmą, pvz., pakeičia gavėją arba sukelia išimtį.

Apibendrinant galima teigti, kad supratimas apie sąvoką "Bang" metodai svetainėje Ruby programinės įrangos kūrimas gali labai pagerinti jūsų kodavimo įgūdžius ir suteikti daugiau aiškumo jūsų programinei bazei. "Bang" metodai, žymimi šauktuku jų pavadinimų pabaigoje, nurodo destruktyvią arba potencialiai pavojingą metodo versiją. Pagal susitarimą bang analogas metodą reikėtų naudoti atsargiai, nes jis gali tiesiogiai modifikuoti objektus, nesukuriant atskiros kopijos. Tai gali būti ypač naudinga, kai dirbama su kintamais objektais arba kai reikia optimizuoti našumą. Tačiau svarbu atsargiai naudoti sprogimo metodus, nes netinkamai elgiantis su jais gali kilti nenumatytų pasekmių. Taip pat verta paminėti, kad ne visi metodai turi "Bang" versija, o jų buvimą reikėtų vertinti kiekvienu konkrečiu atveju. Žinodami, kada ir kaip kurti sprogimo metodus, galite veiksmingai naudotis šia galinga priemone ir rašyti švarų, efektyvų kodą, atitinkantį konkrečius reikalavimus.