Ruby-ohjelmistojen kehittäminen: Pamausmenetelmät ja tavat niiden luomiseen

Saatamme usein törmätä toteamukseen, jonka mukaan bang-menetelmä on tavallaan vaarallinen menetelmä, ja määritelmän lopussa oleva huutomerkki kehottaa meitä olemaan valppaana, kun käytämme tätä menetelmää. Katsotaanpa: mitä tämä uhka tarkalleen ottaen on, kun kyse on näistä menetelmistä, ja mitkä ovat niiden ominaisuudet?

Paukkumenetelmien ominaispiirteet

1. Bang-menetelmä vaihtaa vastaanottajan

Yksi tämäntyyppisten menetelmien suosituimmista ominaisuuksista on se, että ne yleensä vaihtavat yleisöä. Katsotaanpa esimerkkinä map! -menetelmää. Dokumentaation mukaan metodi map! kutsuu annettua lohkoa kerran jokaisen selfin elementin kohdalla ja korvaa elementin lohkon palauttamalla arvolla, ja jos lohkoa ei ole annettu, sen sijaan palautetaan 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

Kuten näemme, object_id pysyy muuttumattomana. Tällaisen menetelmän käytön vaara vaikuttaa siis ilmeiseltä. Jos meidän koodi käytimme muuttujaa arry jossain muualla, niin kartta! muuttaa sen. Tämä voi johtaa siihen, että ohjelmamme toimii epätoivotulla tavalla tai jopa kaatuu.

On olemassa esineitä Ruby joita ei voi muuttaa, kuten Integer-, Float- ja Symbol-luokkien esiintymät. Kun työskentelet projekti, voit myös tavata niin sanotun taikakommentin, joka menee näin:

frozenstringliteral: true

Jos yrität muuttaa merkkijonon vastaanottajaa koodissa, jossa tällaista kommenttia on käytetty, saat seuraavanlaisen virheen:

 'abc'.upcase!
 FrozenError (jäädytettyä merkkijonoa ei voi muuttaa)

Mielenkiintoista on, että suunnitelmissa oli ottaa käyttöön muuttumaton merkkijono vuonna Ruby 3.0, mutta Tätä muutosta päätettiin olla tekemättä.. On kuitenkin muistettava, että kaikki bang-menetelmät eivät vaihda vastaanottajaa, joten sinun on aina tarkistettava dokumentaatiosta, millainen vaara on odotettavissa tietyn menetelmän tapauksessa.

2. Bang-menetelmä aiheuttaa poikkeuksen

Toinen näiden menetelmien erityispiirre on se, että monet niistä aiheuttavat poikkeuksen. Esimerkki tällaisesta metodista on ActiveRecord::FinderMethods#first! Dokumentaation mukaan metodi first! on sama kuin ensimmäinen, mutta se herättää hälytyksen ActiveRecord::RecordNotFound, jos tietuetta ei löydy. Huomaa, että first! ei hyväksy argumentteja.

Tiedosto activerecord/lib/activerecord/relation/findermethods.rb, rivi 128

def first!
first || raiserecordnotfoundexception!
end

Edellä käytetty ActiveRecord::FinderMethods#first-metodi näyttää kuitenkin tältä:

Tiedosto activerecord/lib/activerecord/relation/findermethods.rb, rivi 116

def first(limit = nil)
checkreorderdeprecation unless loaded?

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

Kiitos edellä mainituista esimerkeistä, näemme edellisen käyttämisen vaaran. Jos käytämme ActiveRecord::FinderMethods#find! ja se ei löydä sopivaa tietuetta tietokannasta, se palauttaa ActiveRecord::RecordNotFound, mikä voi aiheuttaa ohjelmamme toiminnan loppumisen.

On kuitenkin muistettava, että tämä ei tarkoita, että jos metodin lopussa ei ole huutomerkkiä, se on turvallinen eikä aiheuta poikkeusta tai muuta vastaanottajaa.

Ruby on Rails 6.0:ssa otettiin käyttöön uusi menetelmäpari: ActiveRecord::Persistence::ClassMethods#insert_all ja ActiveRecord::Persistence::ClassMethods#insert_all!

Ensimmäinen näistä menetelmistä on jo jossain määrin vaarallinen. No, dokumentaation mukaan insertkaikki lisää useita tietueita tietokantaan yhdellä SQL INSERT -lausekkeella. Se ei toteuta mitään malleja eikä laukaise ActiveRecordin takaisinkutsuja tai validointeja. Insertall! nostaa lisäksi hälytyksen ActiveRecord::RecordNotUnique, jos jokin rivi rikkoo taulukon yksilöivää indeksiä. Tällöin rivejä ei lisätä. Tämä tarkoittaa, että ensimmäinen näistä metodeista tallentaa kaikki tietueet lukuun ottamatta niitä, jotka rikkovat yksilöivää indeksiä, kun taas toinen (vaarallisempi) metodi aiheuttaa poikkeuksen eikä tallenna yhtään tietuetta tietokantaan.

3. Bang-menetelmällä on vastine ilman huutomerkkiä.

Monet menetelmät ovat vaarallisia käyttää, vaikka niiden lopussa ei olisikaan huutomerkkiä. Esimerkiksi ActiveRecord::FinderMethods#find. Dokumentaation mukaan Jos yhtä tai useampaa tietuetta ei löydy pyydetyille tunnuksille, tulee ilmoitus ActiveRecord::RecordNotFound.

Näemme, että vaikka tämä menetelmä on yhtä vaarallinen kuin ActiveRecord::FinderMethods#first!, siinä ei ole huutomerkkiä.

Sama pätee myös vastaanottajan muuttamiseen. Esimerkiksi Array.delete (kuten dokumentoitu) poistaa kaikki elementit itsestä, jotka ovat yhtä suuria kuin object, ja palauttaa viimeisen poistetun elementin tai nil:n, jos vastaavia elementtejä ei löydy.

 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

Näet selvästi, että kohdetta on muutettu. Yhteistä näille kahdelle metodille on se, että niillä ei ole huutomerkkiä vastaavaa. Jos siis metodilla, jonka haluamme luoda, olisi edellä mainitsemani kaltaisia vaaroja, sen lopussa ei tarvitse olla heti huutomerkkiä. Lisäksi on suositeltavaa luoda bang-metodi, jos on jo olemassa samanniminen metodi, joka on vähemmän vaarallinen kuin metodi, jonka haluat luoda.

Milloin bang-menetelmiä käytetään

Voit ihmetellä, miksi käyttää näitä vaarallisia menetelmiä ylipäätään, varsinkin kun meillä on yleensä vähemmän vaarallisia vastineita. Yksi eduista voi olla esimerkiksi koodin suorituskyvyn paraneminen luotujen objektien määrän vähentämisen ansiosta. Täältä voit lukea lisää Railsin suorituskyvyn parantamisesta..

Poikkeusten aiheuttamisen osalta create-metodin käyttäminen vaarallisen create!:n sijaan voi johtaa tilanteeseen, jossa sovelluksemme virhettä on vaikea havaita, koska tietueita ei kirjoiteta tietokantaan. Jos siis olemme varmoja siitä, että metodille antamamme parametrit ovat oikein, kannattaa käyttää create! -metodia, joka aiheuttaa poikkeuksen, jos tietuetta ei jostain syystä tallenneta tietokantaan.

Johtopäätös on yksinkertainen, ja se kuuluu seuraavasti: tällaisten menetelmien harkittu käyttö voi parantaa koodimme suorituskykyä ja laatua. Meidän on kuitenkin aina muistettava, että niiden epäasianmukainen käyttö voi estää koodia toimimasta kunnolla.

Milloin kannattaa luoda oma bang-menetelmä

Jos haluat rakentaa oman vaarallisen menetelmän, sinun on käytävä läpi tietty päätöksentekoprosessi. Ensin on kysyttävä, onko jo olemassa metodi, jolla on sama nimi kuin sillä, jonka haluat luoda, mutta joka on vähemmän vaarallinen. Voit myös harkita sellaisen metodiparin luomista, jossa toinen metodeista vastaa toista, mutta on vain vaarallisempi.

Ei ole mitään järkeä luoda bang-metodia, jos sen vastinetta ilman huutomerkkiä ei ole olemassa. On metodeja, jotka ovat vaarallisia, koska ne muuttavat objektia tai herättävät poikkeuksen, ja silti niiden nimen lopussa ei ole huutomerkkiä. Jos luot bang-metodin, jolla ei ole vastinetta, se hämmentää koodia käyttävää ohjelmoijaa. Tämä ei osaisi sanoa, mikä tämän metodin vaarallisuus on ja miksi se ansaitsee huutomerkin nimensä lopussa.

Toiseksi meidän on pohdittava, millaisista vaaroista on kyse. Yllä olevista esimerkeistä voidaan päätellä, että yleisin vaaratyyppi on itse objektin muuttaminen (sen sijaan, että luotaisiin sen kopio) tai poikkeuksen aiheuttaminen. Tämä ei tietenkään ole sääntö, vaan pikemminkin Rubyssä ja Ruby on Rails:ssä määriteltyjen metodien analysoinnin tulos. Voimme esimerkiksi tarkastella metodiparin toteutusta, jossa metodi ilman huutomerkki tallentaisi tietueen tietokantaan, kun taas menetelmä, jossa on huutomerkki, ohittaisi tämän tietueen validoinnin. Tässä tapauksessa on selvää, missä tällaisten menetelmien käytön mahdollinen vaara piilee.

Yhteenveto

Yhteenveto paukkumenetelmiä koskevasta tietämyksestä johtaa seuraaviin johtopäätöksiin: 1. menetelmällä, jossa on huutomerkki, on vähemmän uhkaava vastine ilman huutomerkkiä, toiseksi menetelmä, jossa on huutomerkki, suorittaa vaarallisen toiminnon, esimerkiksi muuttaa vastaanottajaa tai aiheuttaa poikkeuksen.

Yhteenvetona voidaan todeta, että käsitteen bang-menetelmät osoitteessa Ruby ohjelmistokehitys voi parantaa huomattavasti koodaustaitojasi ja selkeyttää koodipohjaasi. Bang-menetelmät, jotka on merkitty huutomerkillä nimiensä lopussa, ilmaisevat menetelmän tuhoisan tai mahdollisesti vaarallisen version. Yleissopimuksen mukaan bang vastine metodia tulisi käyttää varoen, sillä se voi muuttaa objekteja suoraan ilman erillisen kopion luomista. Tämä voi olla erityisen hyödyllistä, kun käsitellään muuttuvia objekteja tai kun suorituskyvyn optimointi on tärkeää. On kuitenkin tärkeää noudattaa varovaisuutta bang-metodien käytössä, sillä niillä voi olla tahattomia seurauksia, jos niitä ei käsitellä oikein. On myös syytä huomata, että kaikilla metodeilla ei ole bang-versioja niiden esiintyminen olisi arvioitava tapauskohtaisesti. Kun tiedät, milloin ja miten bang-metodeja luodaan, voit käyttää tätä tehokasta työkalua tehokkaasti ja kirjoittaa puhdasta, tehokasta koodia, joka täyttää erityisvaatimuksesi.