Vývoj softwaru v jazyce Ruby: Metody Bang a způsoby jejich vytváření

Často se můžeme setkat s tvrzením, že metoda třesku je v jistém smyslu nebezpečná metoda a vykřičník na konci její definice vypovídá o tom, že metoda třesku je nebezpečná. nás být při používání této metody ostražitý. Podívejme se: co přesně je touto hrozbou, pokud jde o tyto metody, a jaké jsou jejich charakteristiky?

Charakteristika metod třesku

1. Metoda bang mění příjemce

Jednou z nejoblíbenějších vlastností těchto typů metod je, že obvykle mění své publikum. Podívejme se na příklad metody map! Podle dokumentace metoda map! vyvolá daný blok jednou pro každý prvek self, přičemž prvek nahradí hodnotou vrácenou blokem, a pokud není blok zadán, vrátí místo něj 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

Jak vidíme, object_id zůstává beze změny. Nebezpečí použití takové metody se tedy zdá být zřejmé. Pokud v našem kód jsme proměnnou arry použili kdekoli jinde, pak ji mapa! změní. To může vést k nežádoucímu fungování našeho programu nebo dokonce k jeho pádu.

Existují objekty v Ruby které nelze změnit, například instance tříd Integer, Float a Symbol. Při práci na projekt, můžete se také setkat s tzv. magickým komentářem, který zní takto:

frozenstringliteral: true

Pokus o změnu příjemce řetězce v kódu, kde byl takový komentář použit, by vedl k této chybě:

 'abc'.upcase!
 FrozenError (nelze upravit zmrazený řetězec)

Zajímavé je, že se plánovalo zavedení neměnného řetězce v. Ruby 3.0, ale bylo rozhodnuto tuto změnu neprovádět. Je však třeba mít na paměti, že ne všechny metody bang mění příjemce, takže byste si měli vždy v dokumentaci ověřit, jaké nebezpečí máte v případě konkrétní metody očekávat.

2. Metoda bang vyvolá výjimku

Dalším charakteristickým rysem těchto metod je, že u mnoha z nich je vyvolána výjimka. Příkladem takové metody je ActiveRecord::FinderMethods#first! Podle dokumentace je metoda first! stejná jako metoda first, ale vyvolává chybu ActiveRecord::RecordNotFound, pokud není nalezen žádný záznam. Všimněte si, že metoda first! nepřijímá žádné argumenty.

Soubor activerecord/lib/activerecord/relation/findermethods.rb, řádek 128

def first!
first || raiserecordnotfoundexception!
end

Výše uvedená metoda ActiveRecord::FinderMethods#first však vypadá takto:

Soubor activerecord/lib/activerecord/relation/findermethods.rb, řádek 116

def first(limit = nil)
checkreorderdeprecation unless loaded?

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

Díky výše uvedeným příkladům tak vidíme nebezpečí použití prvního z nich. Pokud použijeme ActiveRecord::FinderMethods#find! a ten nenajde v databázi vhodný záznam, pak vrátí ActiveRecord::RecordNotFound, což může způsobit, že náš program přestane fungovat.

Musíme si však uvědomit, že to neznamená, že pokud metoda nemá na konci vykřičník, je bezpečná a nevyvolá výjimku ani nezmění příjemce.

Nová dvojice metod byla zavedena v Ruby on Rails 6.0: ActiveRecord::Persistence::ClassMethods#insert_all a ActiveRecord::Persistence::ClassMethods#insert_all!

První z těchto metod již vykazuje určitou míru nebezpečí. Podle dokumentace vložtevšechny vloží do databáze více záznamů v jediném příkazu SQL INSERT. Neinstancuje žádné modely ani nespustí zpětná volání ActiveRecord nebo validace. Vloženíall! navíc vyvolá ActiveRecord::RecordNotUnique, pokud některý řádek porušuje jedinečný index tabulky. V takovém případě se nevloží žádné řádky. To znamená, že první z těchto metod uloží všechny záznamy kromě těch, které porušují jedinečný index, zatímco druhá (nebezpečnější) metoda vyvolá výjimku a žádný ze záznamů do databáze neuloží.

3. Metoda bang má ekvivalent bez vykřičníku

Mnohé metody, i když nemají na konci vykřičník, jsou nebezpečné. Například ActiveRecord::FinderMethods#find. Podle dokumentace Pokud pro požadované id nelze najít jeden nebo více záznamů, pak se vyvolá ActiveRecord::RecordNotFound.

Vidíme, že ačkoli má tato metoda stejný stupeň nebezpečnosti jako ActiveRecord::FinderMethods#first!, nemá vykřičník.

Totéž platí pro úpravu příjemce. Například funkce Array.delete (jak je zdokumentováno) odstraní všechny položky ze self, které se rovnají objektu, a vrátí poslední odstraněnou položku nebo nil, pokud nejsou nalezeny žádné odpovídající položky.

 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

Zřetelně vidíte, že objekt byl upraven. Obě metody mají společné to, že nemají ekvivalent vykřičníku. Pokud by tedy metoda, kterou chceme vytvořit, měla takové nebezpečí, jaké jsem zmínil výše, nemusí mít hned na konci vykřičník. Navíc je vhodné vytvořit metodu s vykřičníkem, pokud již existuje metoda se stejným názvem, která je méně nebezpečná než metoda, kterou chceme vytvořit.

Kdy použít metody třesku

Můžete se ptát, proč tyto nebezpečné metody vůbec používat, zvláště když máme obvykle méně nebezpečné protějšky. Jednou z výhod může být například vyšší výkonnost kódu díky snížení počtu vytvářených objektů. Zde si můžete přečíst více o zvyšování výkonu systému Rails..

Pokud jde o vyvolávání výjimek, použití metody create místo nebezpečného create! může vést k tomu, že chybu v naší aplikaci bude obtížné odhalit, protože záznamy nebudou zapsány do databáze. Pokud jsme si tedy jisti, že parametry, které této metodě předáváme, jsou správné, měli bychom použít metodu create!, která vyvolá výjimku, pokud se z nějakého důvodu záznam do databáze neuloží.

Závěr je jednoduchý a zní: rozumné používání těchto metod může zlepšit výkon a kvalitu našeho kódu. Vždy však musíme mít na paměti, že jejich nevhodné použití může zabránit správnému běhu kódu.

Kdy vytvořit vlastní metodu třesku

Pokud chcete vytvořit vlastní nebezpečnou metodu, musíte projít určitým rozhodovacím procesem. Nejprve je třeba se zeptat, zda již neexistuje metoda se stejným názvem jako ta, kterou chcete vytvořit, ale méně nebezpečná. Můžete také zvážit vytvoření dvojice metod, kdy jedna z nich je ekvivalentní druhé, jen je nebezpečnější.

Nemá smysl vytvářet metodu bang, pokud neexistuje její protějšek bez vykřičníku. Existují metody, které jsou nebezpečné, protože mění objekt nebo vyvolávají výjimku, a přesto nemají na konci názvu vykřičník. Vytvoření metody bang bez ekvivalentu by programátora používajícího váš kód zmátlo. Ten by nebyl schopen říci, v čem spočívá nebezpečnost této metody a proč si zaslouží vykřičník na konci svého názvu.

Za druhé bychom měli zvážit, o jakých nebezpečích hovoříme. Z výše uvedených příkladů můžeme vyvodit, že nejčastějším typem nebezpečí je změna samotného objektu (namísto vytvoření jeho kopie) nebo vyvolání výjimky. Samozřejmě se nejedná o pravidlo, ale spíše o výsledek analýzy metod, které byly definovány v jazycích Ruby a Ruby on Rails. Můžeme například uvažovat o implementaci dvojice metod, v níž metoda bez příznaku vykřičník by záznam uložil do databáze, zatímco metoda s vykřičníkem by validaci tohoto záznamu přeskočila. V tomto případě je zřejmé, v čem spočívá potenciální nebezpečí používání takových metod.

Souhrn

Shrnutí poznatků o metodách třesku ukazuje na tyto závěry: 1. metoda s vykřičníkem má méně ohrožující bez vykřičníku, za druhé metoda s vykřičníkem provede nebezpečnou akci, např. změní příjemce nebo vyvolá výjimku.

Závěrem lze říci, že pochopení konceptu metody třesku na adrese Ruby vývoj softwaru může výrazně zlepšit vaše kódovací dovednosti a zpřehlednit vaši kódovou základnu. Metody Bang, označené vykřičníkem na konci názvu, označují destruktivní nebo potenciálně nebezpečnou verzi metody. Podle konvence se bang protějšek metody by se měl používat opatrně, protože může přímo měnit objekty, aniž by se vytvořila jejich samostatná kopie. To může být užitečné zejména při práci s proměnlivými objekty nebo v případech, kdy jde o optimalizaci výkonu. Při používání metod bang je však třeba dbát zvýšené opatrnosti, protože při nesprávném zacházení mohou mít nechtěné důsledky. Stojí také za zmínku, že ne všechny metody mají tzv. verze banga jejich přítomnost by měla být posuzována případ od případu. Se znalostí toho, kdy a jak vytvářet metody bang, můžete tento mocný nástroj efektivně ovládat a psát čistý a efektivní kód, který splňuje vaše specifické požadavky.