5 Ruby labākā lietojuma piemēri
Vai esat kādreiz aizdomājušies, ko mēs varam darīt ar Ruby? Iespējams, debesis ir neierobežotas, taču mēs labprāt pastāstīsim par dažiem vairāk vai mazāk zināmiem gadījumiem...
Pirms sākam veidot sprādziena metodi, uzzināsim, kas tieši ir šāda veida metode un kādas ir tās īpašības. Sāksim ar to, ka šāda veida metodēm nav viennozīmīgas definīcijas. Vienkāršāk sakot, sprādziena metode ir metode ar izsaukuma zīmi beigās.
Mēs bieži varam sastapties ar apgalvojumu, ka sprādziena metode savā ziņā ir bīstama metode, un tās definīcijas beigās esošais izsaukuma zīme liecina par to. mums lietojot šo metodi, jābūt uzmanīgiem. Apskatīsim: kas tieši ir šie draudi, kad runa ir par šīm metodēm, un kādas ir to īpašības?
Viena no populārākajām šāda veida metožu īpašībām ir tā, ka tās parasti maina auditoriju. Kā piemēru aplūkosim metodi "karte!". Saskaņā ar dokumentāciju metode map! katram self elementam vienreiz izsauc doto bloku, aizstājot elementu ar bloka atdoto vērtību, un, ja nav dots neviens bloks, tā vietā tiek atdots enumerators.
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
Kā redzams, object_id paliek nemainīgs. Tādējādi šādas metodes izmantošanas bīstamība šķiet acīmredzama. Ja mūsu kods mēs izmantojām mainīgo arry jebkur citur, tad karte! to mainīs. Tas var izraisīt nevēlamu programmas darbību vai pat tās sabrukumu.
Ir objekti Rubīns kurus nevar mainīt, piemēram, klases Integer, Float un Symbol gadījumus. Strādājot ar projekts, jūs varat arī sastapties ar tā saukto burvju komentāru, kas ir šāds:
frozenstringliterāls: true
Mēģinājums mainīt virknes saņēmēju kodā, kurā tika izmantots šāds komentārs, izraisītu šādu kļūdu:
'abc'.upcase!
FrozenError (nevar modificēt iesaldētu virkni)
Interesanti, ka tika plānots ieviest nemainīgu virkni in Rubīns 3.0, bet tika nolemts šo izmaiņu neveikt.. Tomēr jāatceras, ka ne visas sprādziena metodes maina saņēmēju, tāpēc dokumentācijā vienmēr jāpārbauda, kādas briesmas sagaidāmas konkrētās metodes gadījumā.
Vēl viena šo metožu īpatnība ir tā, ka daudzām no tām tiek radīts izņēmums. Šādas metodes piemērs ir ActiveRecord::FinderMethods#first! Saskaņā ar dokumentāciju metode first! ir tāda pati kā metode first, bet izraisa ActiveRecord::RecordNotFound, ja nav atrasts neviens ieraksts. Ņemiet vērā, ka metode first! nepieņem argumentus.
Faila activerecord/lib/activerecord/relation/findermethods.rb, 128. rinda
def first!
first || raiserecordnotfoundexception!
end
Tomēr iepriekš izmantotā ActiveRecord::FinderMethods#first metode izskatās šādi:
Faila activerecord/lib/activerecord/relation/findermethods.rb, 116. rinda
def first(limit = nil)
checkreorderdeprecation unless loaded?
if limit
findnthwithlimit(0, limit)
else
findnth 0
end
end
Pateicoties iepriekš minētajiem piemēriem, mēs redzam, cik bīstami ir izmantot pirmo no minētajām iespējām. Ja mēs izmantosim ActiveRecord::FinderMethods#find! un tas neatradīs datubāzē piemērotu ierakstu, tad tas atgriezīs ActiveRecord::RecordNotFound, kas var izraisīt mūsu programmas darbības pārtraukšanu.
Tomēr jāatceras, ka tas nenozīmē, ka, ja metodes beigās nav izsaukuma zīmes, tā ir droša un neizsauks izņēmumu vai nemainīs saņēmēju.
Tika ieviests jauns metožu pāris Ruby on Rails 6.0: ActiveRecord::Persistence::ClassMethods#insert_all un ActiveRecord::Persistence::ClassMethods#insert_all!
Pirmā no šīm metodēm jau liecina par zināmu bīstamību. Saskaņā ar dokumentāciju, ievietojietar vienu SQL INSERT izteikumu datubāzē ievieto vairākus ierakstus. Tas neievieš nekādus modeļus, kā arī neizraisa ActiveRecord izsaukumus vai validācijas. Tomēr ievietošanasall! papildus izraisa ActiveRecord::RecordNotUnique, ja kāda rinda pārkāpj tabulas unikālo indeksu. Tādā gadījumā rindas netiek ievietotas. Tas nozīmē, ka pirmā no šīm metodēm saglabās visus ierakstus, izņemot tos, kas pārkāpj unikālo indeksu, bet otrā (bīstamākā) metode radīs izņēmumu un datubāzē neizglabās nevienu ierakstu.
Daudzas metodes, pat ja to beigās nav izsaukuma zīmes, ir bīstamas. Piemēram, ActiveRecord::FinderMethods#find. Saskaņā ar dokumentāciju, ja pieprasītajiem identifikatoriem nevar atrast vienu vai vairākus ierakstus, tad tiks parādīta ActiveRecord::RecordNotFound.
Mēs redzam, ka, lai gan šai metodei ir tāda pati bīstamības pakāpe kā ActiveRecord::FinderMethods#first!, tai nav izsaukuma zīmes.
Tas pats attiecas arī uz saņēmēja modificēšanu. Piemēram, Array.delete (kā dokumentēts) dzēš visus vienumus no self, kas ir vienādi ar object, un atgriež pēdējo dzēsto vienumu vai nulli, ja nav atrasts neviens atbilstošs vienums.
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
Var skaidri redzēt, ka objekts ir modificēts. Abām metodēm ir kopīgs tas, ka tām nav izsaukuma zīmes ekvivalenta. Tāpēc, ja metodei, ko vēlamies izveidot, būtu tāda veida bīstamība, kādu es minēju iepriekš, tai nav nepieciešams uzreiz beigās lietot izsaukuma zīmi. Turklāt ir ieteicams izveidot sprādziena zīmi, ja jau ir metode ar tādu pašu nosaukumu, kas ir mazāk bīstama nekā metode, kuru vēlaties izveidot.
Jūs varat brīnīties, kāpēc vispār izmantot šīs bīstamās metodes, jo īpaši tāpēc, ka parasti mums ir mazāk bīstamas metodes. Viena no priekšrocībām var būt, piemēram, uzlabota koda veiktspēja, pateicoties radīto objektu skaita samazināšanai. Šeit varat lasīt vairāk par Rails veiktspējas palielināšanu.
Ja runa ir par izņēmumu radīšanu, izmantojot metodi create, nevis bīstamo create!, var rasties situācija, kad kļūdu mūsu lietojumprogrammā ir grūti atklāt, jo ieraksti netiks ierakstīti datubāzē. Tāpēc, ja esam pārliecināti, ka šai metodei nodotie parametri ir pareizi, mums jāizmanto metode create!, kas radīs izņēmumu, ja kāda iemesla dēļ ieraksts netiks saglabāts datubāzē.
Secinājums ir vienkāršs, un tas ir šāds: apdomīga šādu metožu izmantošana var uzlabot mūsu koda veiktspēju un kvalitāti. Tomēr mums vienmēr jāatceras, ka to nepareiza izmantošana var apturēt pareizu koda darbību.
Ja vēlaties izveidot savu bīstamo metodi, jums ir jāiziet cauri noteiktam lēmumu pieņemšanas procesam. Pirmkārt, jājautā, vai jau pastāv metode ar tādu pašu nosaukumu kā metode, kuru vēlaties izveidot, bet kas nav tik bīstama. Var arī apsvērt iespēju izveidot metožu pāri, kurā viena no tām ir līdzvērtīga otrai, tikai bīstamāka.
Nav jēgas radīt sprādziena metodi, ja tās ekvivalents bez izsaukuma zīmes nepastāv. Ir metodes, kas ir bīstamas, jo maina objektu vai izraisa izņēmumu, un tomēr to nosaukuma beigās nav izsaukuma zīmes. Izveidojot sprādziena metodi bez ekvivalenta, programmētājs, kas izmanto jūsu kodu, tiktu maldināts. Šis cilvēks nespētu pateikt, kāda ir šīs metodes bīstamība un kāpēc tā ir pelnījusi izsaukuma zīmi nosaukuma beigās.
Otrkārt, mums jāapsver, par kādām briesmām mēs runājam. No iepriekš minētajiem piemēriem varam secināt, ka visbiežāk sastopamais briesmu veids ir paša objekta maiņa (tā vietā, lai izveidotu tā kopiju) vai izņēmuma izraisīšana. Protams, tas nav noteikums, bet gan rezultāts, kas izriet no Ruby un Ruby on Sliedes. Piemēram, mēs varam aplūkot metodes pāra implementāciju, kurā metode bez izsaukuma zīme saglabātu ierakstu datubāzē, bet metode ar izsaukuma zīmi izlaistu šī ieraksta validāciju. Šajā gadījumā ir skaidrs, kur slēpjas šādu metožu izmantošanas potenciālais risks.
Sprādziena metožu zināšanu apkopojums ļauj izdarīt šādus secinājumus: 1. metodei ar izsaukuma zīmi ir mazāk bīstami otrkārt, metode ar izsaukuma zīmi veic bīstamu darbību, piemēram, maina saņēmēju vai izraisa izņēmumu.
Nobeigumā jāsecina, ka izpratne par jēdzienu sprādziena metodes vietnē Rubīns programmatūras izstrāde var ievērojami uzlabot jūsu kodēšanas prasmes un padarīt jūsu kodu bāzi skaidrāku. Sprādziena metodes, ar izsaukājzīmi nosaukuma beigās, norāda uz destruktīvu vai potenciāli bīstamu metodes versiju. Saskaņā ar konvenciju sprādziena ekvivalents metodes izmantošana ir piesardzīga, jo tā var tieši modificēt objektus, neizveidojot atsevišķu kopiju. Tas var būt īpaši noderīgi, ja runa ir par mainīgiem objektiem vai ja ir svarīgi optimizēt veiktspēju. Tomēr ir svarīgi ievērot piesardzību, lietojot sprādziena metodes, jo tās var radīt neparedzētas sekas, ja netiek pareizi apstrādātas. Ir vērts arī atzīmēt, ka ne visām metodēm ir sprādziena versija, un to klātbūtne būtu jāizvērtē katrā gadījumā atsevišķi. Apgūstot zināšanas par to, kad un kā izveidot sprādziena metodes, jūs varat efektīvi izmantot šo spēcīgo rīku un rakstīt tīru, efektīvu kodu, kas atbilst jūsu specifiskajām prasībām.