Ruby software ontwikkeling: Knalmethoden en manieren om ze te maken

We komen vaak tegen dat de bang methode in zekere zin een gevaarlijke methode is en het uitroepteken aan het einde van de definitie vertelt ons dat we waakzaam moeten zijn bij het gebruik van deze methode. Laten we eens kijken: wat is dit gevaar precies als het gaat om deze methoden en wat zijn hun kenmerken?

Kenmerken van knalmethoden

1. De bang-methode verandert de ontvanger

Een van de populairste kenmerken van dit soort methoden is dat ze meestal hun publiek veranderen. Laten we eens kijken naar de map! methode als voorbeeld. Volgens de documentatie roept de map! methode het gegeven blok eenmaal aan voor elk element van self, waarbij het element wordt vervangen door de waarde die door het blok wordt geretourneerd en als er geen blok wordt gegeven, wordt in plaats daarvan een enumerator geretourneerd.

 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

Zoals we kunnen zien, blijft object_id ongewijzigd. Het gevaar van het gebruik van een dergelijke methode lijkt dus duidelijk. Als in onze code we de variabele arry ergens anders hebben gebruikt, dan zal de map! deze veranderen. Dit kan ertoe leiden dat ons programma op een ongewenste manier werkt of zelfs crasht.

Er zijn objecten in Ruby die niet gewijzigd kunnen worden, zoals instanties van de klassen Integer, Float en Symbol. Tijdens het werken aan een projectJe kunt ook het zogenaamde magische commentaar tegenkomen dat als volgt gaat:

bevrorenstringletterlijk: waar

Pogingen om de ontvanger van de String te wijzigen in de code waar een dergelijke opmerking werd gebruikt, zouden resulteren in een fout zoals deze:

 'abc'.upcase!
 FrozenError (kan bevroren String niet wijzigen)

Interessant genoeg waren er plannen om onveranderlijke String te introduceren in Ruby 3.0maar werd besloten deze wijziging niet door te voeren. Onthoud echter dat niet alle bang-methoden de ontvanger veranderen, dus je moet altijd in de documentatie controleren wat voor gevaar je kunt verwachten in het geval van een bepaalde methode.

2. De bang-methode maakt een uitzondering

Een ander onderscheidend kenmerk van deze methoden is dat voor veel ervan een uitzondering wordt gemaakt. Een voorbeeld van zo'n methode is de ActiveRecord::FinderMethods#first! Volgens de documentatie is de methode first! hetzelfde als de methode first, maar roept ActiveRecord::RecordNotFound op als er geen record wordt gevonden. Merk op dat first! geen argumenten accepteert.

Bestand activerecord/lib/activerecord/relation/findermethods.rb, regel 128

def first!
first || raiserecordnotfoundexception!
end

De ActiveRecord::FinderMethods#first methode die hierboven wordt gebruikt ziet er echter als volgt uit:

Bestand activerecord/lib/activerecord/relation/findermethods.rb, regel 116

def eerste(limiet = nil)
checkreorderdeprecation tenzij geladen?

als limiet
findnthwithlimit(0, limiet)
anders
findnth 0
einde
einde

Dank dus de bovenstaande voorbeelden, zien we het gevaar van het gebruik van de eerste. Als we ActiveRecord::FinderMethods#find! gebruiken en het vindt geen geschikt record in de database, dan zal het ActiveRecord::RecordNotFound retourneren, waardoor ons programma kan stoppen met werken.

We moeten echter onthouden dat dit niet betekent dat als een methode geen uitroepteken aan het einde heeft, deze veilig is en geen exceptie zal oproepen of de ontvanger zal veranderen.

In Ruby on Rails 6.0 is een nieuw paar methoden geïntroduceerd: ActiveRecord::Persistence::ClassMethods#insert_all en ActiveRecord::Persistence::ClassMethods#insert_all!

De eerste van deze methoden vertoont al een zekere mate van gevaar. Welnu, volgens de documentatie is het invoegen vanvoegt meerdere records in de database in met een enkele SQL INSERT-instructie. Er worden geen modellen geïnstantieerd en er worden geen ActiveRecord callbacks of validaties geactiveerd. De insertall! roept bovendien ActiveRecord::RecordNotUnique op als rijen een unieke index op de tabel schenden. In dat geval worden er geen rijen ingevoegd. Dit betekent dat de eerste methode alle records opslaat behalve diegene die de unieke index schenden, terwijl de tweede (gevaarlijkere) methode een uitzondering oproept en geen records opslaat in de database.

3. De bang-methode heeft een equivalent zonder uitroepteken

Veel methoden zijn gevaarlijk om te gebruiken, ook al hebben ze geen uitroepteken aan het einde. Bijvoorbeeld ActiveRecord::FinderMethods#find. Volgens de documentatie Als een of meer records voor de opgevraagde id's niet kunnen worden gevonden, wordt ActiveRecord::RecordNotFound opgeworpen.

We kunnen zien dat, hoewel deze methode dezelfde mate van gevaar heeft als ActiveRecord::FinderMethods#first!, deze geen uitroepteken heeft.

Hetzelfde geldt voor het wijzigen van de ontvanger. Bijvoorbeeld, Array.delete (zoals gedocumenteerd) verwijdert alle items van de self die gelijk zijn aan object en retourneert het laatst verwijderde item, of nil als er geen overeenkomende items zijn gevonden.

 a = [1, 2, 3, 4, 5]
 a.object_id #=> 320
 a.verwijderen(2) #=> 2
 a #=> [1, 3, 4, 5]
 a.verwijderen(6) #=> nil
 a.object_id #=> 320

Je kunt duidelijk zien dat het object is gewijzigd. Wat de twee methoden gemeen hebben, is dat ze geen uitroepteken-equivalent hebben. Daarom, als de methode die we willen maken het soort gevaren zou hebben dat ik hierboven noemde, hoeft het niet meteen een uitroepteken aan het einde te hebben. Bovendien is het aan te raden om een bang method te maken als er al een methode is met dezelfde naam die minder gevaarlijk is dan de methode die je wilt maken.

Wanneer knalmethoden gebruiken

Je kunt je afvragen waarom je deze gevaarlijke methoden überhaupt gebruikt, vooral omdat we meestal minder gevaarlijke tegenhangers hebben. Een van de voordelen kan bijvoorbeeld een verbeterde codeprestatie zijn dankzij het verminderen van het aantal objecten dat wordt aangemaakt. Hier kun je meer lezen over het verhogen van de prestaties van Rails.

Als het gaat om het oproepen van uitzonderingen, kan het gebruik van de methode create in plaats van het gevaarlijke create! leiden tot een situatie waarin een fout in onze applicatie moeilijk te detecteren is, omdat de records niet naar de database worden geschreven. Dus, als we zeker weten dat de parameters die we doorgeven aan deze methode correct zijn, kunnen we beter de create! methode gebruiken, die een exceptie zal oproepen als, om wat voor reden dan ook, het record niet wordt opgeslagen in de database.

De conclusie is eenvoudig en luidt als volgt: verstandig gebruik van dergelijke methoden kan de prestaties en kwaliteit van onze code verbeteren. We moeten echter altijd onthouden dat ongepast gebruik ervoor kan zorgen dat de code niet meer goed werkt.

Wanneer maak je je eigen knalmethode

Als je je eigen gevaarlijke methode wilt maken, moet je een bepaald besluitvormingsproces doorlopen. Ten eerste is de vraag of er al een methode bestaat met dezelfde naam als degene die je wilt maken, maar dan minder gevaarlijk. Je kunt ook overwegen om een paar methodes te maken waarvan de ene gelijkwaardig is aan de andere, alleen gevaarlijker.

Het heeft geen zin om een knalmethode te maken als zijn tegenhanger zonder uitroepteken niet bestaat. Er zijn methodes die gevaarlijk zijn omdat ze het object veranderen of een exception oproepen, en toch hebben ze geen uitroepteken aan het einde van de naam. Het maken van een bang method zonder equivalent zou een programmeur die je code gebruikt in verwarring brengen. Deze persoon zou niet kunnen zeggen wat het gevaar van deze methode is en waarom het een uitroepteken aan het einde van de naam verdient.

Ten tweede moeten we overwegen over wat voor soort gevaren we het hebben. Uit de bovenstaande voorbeelden kunnen we concluderen dat het meest voorkomende type gevaar het veranderen van het object zelf is (in plaats van het maken van een kopie) of het oproepen van een exception. Natuurlijk is dit geen regel, maar eerder een resultaat van het analyseren van de methodes die zijn gedefinieerd in Ruby en Ruby on Rails. We kunnen bijvoorbeeld kijken naar de implementatie van een methodepaar waarbij de methode zonder de uitroepteken zou de record opslaan in de database, terwijl de methode met het uitroepteken de validatie van deze record zou overslaan. In dit geval is het duidelijk waar het potentiële gevaar van het gebruik van dergelijke methoden ligt.

Samenvatting

Een samenvatting van de kennis van knalmethoden leidt tot de volgende conclusies: de 1e methode met het uitroepteken heeft een minder bedreigend tegenhanger zonder uitroepteken, ten tweede voert de methode met een uitroepteken een gevaarlijke actie uit, bijvoorbeeld de ontvanger wijzigen of een uitzondering oproepen.

Concluderend kan worden gesteld dat het begrijpen van het concept van knalmethoden in Ruby softwareontwikkeling kan je codeervaardigheden enorm verbeteren en meer duidelijkheid brengen in je codebase. Knalmethoden, aangeduid met een uitroepteken aan het einde van hun naam, geven een destructieve of potentieel gevaarlijke versie van een methode aan. Volgens conventie wordt de bang tegenhanger van een methode moet met voorzichtigheid gebruikt worden, omdat het objecten direct kan wijzigen, zonder een aparte kopie te maken. Dit kan bijzonder nuttig zijn wanneer je te maken hebt met muteerbare objecten of wanneer prestatie-optimalisatie van belang is. Het is echter belangrijk om voorzichtig te zijn bij het gebruik van bang methods, omdat ze onbedoelde gevolgen kunnen hebben als er niet goed mee wordt omgegaan. Het is ook de moeite waard om op te merken dat niet alle methoden een knalversieen hun aanwezigheid moet van geval tot geval worden beoordeeld. Met de kennis over wanneer en hoe je bang methods moet maken, kun je dit krachtige gereedschap effectief gebruiken en schone, efficiënte code schrijven die voldoet aan je specifieke eisen.