Ruby forritunarþróun: Bang-aðferðir og leiðir til að búa þær til

Við gætum oft rekist á þá yfirlýsingu að bang-aðferðin sé, í vissum skilningi, hættuleg aðferð og hástafurinn við endi skilgreiningar hennar segir okkur að vera á varðbergi þegar þessari aðferð er beitt. Skoðum nánar: hvað er ógnin nákvæmlega þegar kemur að þessum aðferðum og hvaða einkenni hafa þær?

Eiginleikar bang-aðferða

1. Bang-aðferðin breytir viðtakandanum

Ein af vinsælustu einkennum þessara tegunda aðferða er að þær breyta venjulega markhópi sínum. Tökum map!-aðferðina sem dæmi. Samkvæmt skjölum kallar map!-aðferðin gefið blokk einu sinni fyrir hvern þátt í self og skiptir út þættinum fyrir gildi sem blokkurinn skilar, en ef ekkert blokk er gefið er skilað Enumerator í staðinn.

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 => 280Hljóðskrift

Eins og við sjáum, stendur object_id óbreytt. Því virðist hættan við að nota slíka aðferð augljós. Ef í okkar kóði Ef við notum breytuna arry annars staðar, mun kortið breyta því. Þetta getur leitt til þess að forritið okkar starfi óæskilega eða jafnvel hrundi.

Það eru hlutir í Rúbín sem ekki er hægt að breyta, svo sem dæmi um Integer-, Float- og Symbol-flokka. Á meðan unnið er að verkefni, þú gætir líka rekist á svokallaða töfrathugsemina sem hljómar svona:

frystur strengsbókstafur: satt

Að reyna að breyta String-móttakaranum í kóðanum þar sem slík athugasemd var notuð myndi leiða til villu eins og þessarar:

'abc'.upcase!
FrozenError (ekki hægt að breyta frosnu strengi)Hljóðskrift

Áhugavert var að áætlanir voru um að kynna óbreytanlegan String í Rúbín 3.0, en Ákveðið var að gera ekki þessa breytingu.. Hins vegar skal hafa í huga að ekki allar bang-aðferðir breyta viðtakandanum, svo þú ættir alltaf að athuga í skjölunum hvaða hættu þú ættir að búast við í tilviki tiltekinnar aðferðar.

2. bang-aðferðin kallar fram undantekningu

Annað einkenni þessara aðferða er að hjá mörgum þeirra er kastað undantekningu. Dæmi um slíka aðferð er ActiveRecord::FinderMethods#first! Samkvæmt skjölunum er first!-aðferðin sú sama og first-aðferðin en kallar ActiveRecord::RecordNotFound ef engin skrá finnst. Athugaðu að first! tekur engin rök.

Skrá activerecord/lib/activerecord/relation/findermethods.rb, lína 128

def first!
first || raiserecordnotfoundexception!
end

Hins vegar lítur fyrsta ActiveRecord::FinderMethods#first-aðferðin sem notuð er hér að ofan svona út:

Skrá activerecord/lib/activerecord/relation/findermethods.rb, lína 116

def first(limit = nil)
checkreorderdeprecation unless loaded?

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

Með hliðsjón af ofangreindum dæmum sjáum við hættuna við að nota hið fyrrnefnda. Ef við notum ActiveRecord::FinderMethods#find! og það finnur ekki viðeigandi skrá í gagnagrunninum, mun það skila ActiveRecord::RecordNotFound, sem getur valdið því að forritið okkar hætti að virka.

Hins vegar verðum við að muna að þetta þýðir ekki að ef aðferð hefur ekki undirrót við lokin sé hún örugg og muni hvorki kasta undantekningu né breyta móttakandanum.

Nýtt par aðferða var kynnt í Ruby on Rails 6.0: ActiveRecord::Persistence::ClassMethods#insert_all og ActiveRecord::Persistence::ClassMethods#insert_all!

Fyrsta aðferðin sýnir þegar ákveðna hættu. Jæja, samkvæmt skjölunum, settu innall inserts multiple records into the database in a single SQL INSERT statement. It does not instantiate any models nor does it trigger ActiveRecord callbacks or validations. However, the insertall! kallar einnig fram ActiveRecord::RecordNotUnique ef einhverjar raðir brjóta gegn einstakri vísitölu í töflunni. Í því tilfelli eru engar raðir skráðar. Þetta þýðir að sú fyrri aðferðin mun vista öll gögn nema þau sem brjóta gegn einstöku vísitölu, en sú seinni (hættulegri) aðferðin mun kalla fram undantekningu og vista engin gögn í gagnagrunninn.

3. Bang-aðferðin hefur jafngildi án undrunarmerkis.

Margir aðferðir, jafnvel þótt þær beri ekki upphrópunarmerki í lokin, eru hættulegar í notkun. Til dæmis ActiveRecord::FinderMethods#find. Samkvæmt skjölun, ef eitt eða fleiri skrárit finnast ekki fyrir beiðnar auðkenni, verður ActiveRecord::RecordNotFound kastað.

Við sjáum að þrátt fyrir að þessi aðferð sé jafn hættuleg og ActiveRecord::FinderMethods#first!, þá er ekki hrópaeinkenni í henni.

Sama gildir þegar kemur að því að breyta móttakaranum. Til dæmis eyðir Array.delete (eins og fram kemur í skjölum) öllum þáttum úr sjálfu sér sem eru jafnir hlutnum og skilar síðasta eyddum þættinum, eða nil ef engir samsvarandi þættir finnast.

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 #=> 320Hljóðskrift

Þú sérð greinilega að hluturinn hefur verið breyttur. Það sem þessar tvær aðferðir eiga sameiginlegt er að þær hafa engan samsvarandi !-merki. Þess vegna, ef aðferðin sem við ætlum að búa til myndi fela í sér þær hættur sem ég nefndi hér að ofan, þarf hún ekki strax að bera !-merki í lokin. Ennfremur er ráðlegt að búa til bang-aðferð ef þegar er til aðferð með sama nafni sem er minna hættuleg en sú sem þú vilt búa til.

Hvenær á að nota bang-aðferðir

Þú gætir velt því fyrir þér hvers vegna yfir höfuð nota þessar hættulegu aðferðir, sérstaklega þar sem við höfum yfirleitt minna hættulegar aðferðir til að nota. Einn kostur getur verið, til dæmis, bætt kóðaframmistaða vegna þess að færri hlutir eru búnir til. Hér geturðu lesið meira um hvernig auka má afköst Rails..

Þegar kemur að því að kasta undantekningum, getur notkun `create`-aðferðarinnar í stað hættulegu `create!`-aðferðarinnar leitt til þess að villa í forritinu verði erfið í greina þar sem færslurnar verða ekki skráðar í gagnagrunninn. Ef við erum viss um að breyturnar sem við sendum þessari aðferð séu réttar, ættum við hins vegar að nota `create!`-aðferðina, sem kastar undantekningu ef færslan er af einhverjum ástæðum ekki vistuð í gagnagrunninn.

Ályktunin er einföld og hljómar svona: varkár notkun slíkra aðferða getur bætt frammistöðu og gæði kóðans okkar. Hins vegar verðum við alltaf að muna að óviðeigandi notkun þeirra getur hindrað kóðann í að keyra eðlilega.

Hvenær á að búa til eigin bang-aðferð

Ef þú vilt búa til þína eigin hættulegu aðferð, verður þú að fara í gegnum ákveðið ákvarðanatökuferli. Fyrst er spurningin hvort þegar sé til aðferð með sama nafni og sú sem þú vilt búa til, en sem er minna hættuleg. Þú getur einnig íhugað að búa til par af aðferðum þar sem önnur þeirra er jafngild hinni, en einfaldlega hættulegri.

Það er tilgangslaust að búa til bang-aðferð ef samsvarandi aðferð án undrunarmerkis (ekki með !-merki) er ekki til. Það eru aðferðir sem eru hættulegar vegna þess að þær breyta hlutnum eða kalla fram undantekningu, en samt eru engin undrunarmerki (!) við enda nafnsins. Að búa til bang-aðferð án jafngildis myndi rugla forritara sem notar kóðann þinn. Sá forritari gæti ekki sagt hvað ógnin við þessa aðferð er né hvers vegna hún eigi skilið undrunarmerki (!) við enda nafnsins.

Í öðru lagi ættum við að íhuga hvaða tegund hættu við erum að tala um. Úr dæmunum hér að ofan getum við dregið þá ályktun að algengasta tegund hættu sé breyting á hlutnum sjálfum (í stað þess að búa til afrit af honum) eða að kasta undantekningu. Auðvitað er þetta ekki regla heldur frekar niðurstaða greiningar á aðferðunum sem hafa verið skilgreindar í Ruby og Ruby on Relsar. Til dæmis gætum við íhugað innleiðingu aðferðapars þar sem aðferðin án the upphrópunarmerki Myndu vista færsluna í gagnagrunninum, á meðan aðferðin með hrópsmerkinu myndi sleppa staðfestingu á þessari færslu. Í þessu tilfelli er ljóst hvar möguleg hætta felst í notkun slíkra aðferða.

Yfirlit

Yfirlit yfir þekkingu á bang-aðferðum bendir til þessara niðurstaðna: fyrsta aðferðin með hrópsmerkinu hefur a minni ógn samheiti án hrópsmerkis, í öðru lagi framkvæmir aðferðin með hrópsmerki hættulega aðgerð, t.d. breytir móttakandanum eða kallar fram undantekningu.

Að lokum, skilningur á hugtakinu bang aðferðir í Rúbín hugbúnaðarþróun getur verulega bætt kóðunarhæfileika þína og skapað meiri skýrleika í kóðagrunninum þínum. Bang-aðferðir, merkt með hrópsmerki í lok nafna þeirra, gefa til kynna eyðileggjandi eða hugsanlega hættulega útgáfu aðferðar. Samkvæmt venju, bang-jafngildi aðferð ætti að nota með varúð þar sem hún getur breytt hlutum beint, án þess að búa til sérstaka afrit. Þetta getur verið sérstaklega gagnlegt þegar unnið er með breytilega hluti eða þegar frammistaða er í brennidepli. Hins vegar er mikilvægt að fara varlega þegar bang-aðferðir eru notaðar, því þær geta haft óæskileg áhrif ef ekki er staðið rétt að. Einnig má taka fram að ekki allar aðferðir hafa a bang útgáfa, og tilvist þeirra ætti að meta í hverju tilviki fyrir sig. Með þekkingu á því hvenær og hvernig á að búa til bang-aðferðir geturðu nýtt þetta öfluga tæki á áhrifaríkan hátt og skrifað hreinan, skilvirkan kóða sem uppfyllir þínar sértæku kröfur.