Ruby Software-Entwicklung: Bang-Methoden und Wege, sie zu erstellen

Man stößt oft auf die Aussage, dass die Bang-Methode in gewisser Weise eine gefährliche Methode ist, und das Ausrufezeichen am Ende der Definition mahnt zur Wachsamkeit bei der Anwendung dieser Methode. Was genau ist diese Gefahr bei diesen Methoden und was sind ihre Merkmale?

Merkmale der Knallmethoden

1. Die Knallmethode ändert den Empfänger

Eines der beliebtesten Merkmale dieser Art von Methoden ist, dass sie in der Regel ihr Publikum wechseln. Schauen wir uns als Beispiel die Methode map! an. Der Dokumentation zufolge ruft die Methode map! den angegebenen Block einmal für jedes Element von self auf und ersetzt das Element durch den vom Block zurückgegebenen Wert; wenn kein Block angegeben wird, wird stattdessen ein Enumerator zurückgegeben.

 arry = [1, 2, 3, 4, 5]
 arry.object_id => 280
 arry.map! {} => [1, 4, 27, 256, 3125]
 arry.map!                       => #
 arry.map! {|n| n } => [1, 4, 27, 256, 3125]
 arry.object_id => 280

Wie wir sehen können, bleibt object_id unverändert. Die Gefahr der Verwendung einer solchen Methode scheint also offensichtlich. Wenn in unserem Code Wenn wir die Variable arry an einer anderen Stelle verwenden, wird sie von map! geändert. Dies kann dazu führen, dass unser Programm auf unerwünschte Weise arbeitet oder sogar abstürzt.

Es gibt Objekte in Rubinrot die nicht geändert werden können, wie z. B. Instanzen der Klassen Integer, Float und Symbol. Während der Arbeit an einer Projektkönnen Sie auch auf den so genannten magischen Kommentar treffen, der wie folgt lautet:

eingefrorenerStringliteral: wahr

Der Versuch, den String-Empfänger in dem Code zu ändern, in dem ein solcher Kommentar verwendet wurde, würde zu einem Fehler wie diesem führen:

 'abc'.upcase!
 FrozenError (eingefrorener String kann nicht geändert werden)

Interessanterweise gab es Pläne, einen unveränderlichen String in Ruby 3.0aber es wurde beschlossen, diese Änderung nicht vorzunehmen. Es sollte jedoch bedacht werden, dass nicht alle Bang-Methoden den Empfänger ändern, so dass Sie immer in der Dokumentation nachsehen sollten, welche Art von Gefahr Sie im Falle einer bestimmten Methode zu erwarten haben.

2. Die Methode bang löst eine Ausnahme aus

Eine weitere Besonderheit dieser Methoden ist, dass bei vielen von ihnen eine Ausnahme ausgelöst wird. Ein Beispiel für eine solche Methode ist die ActiveRecord::FinderMethods#first! Laut Dokumentation ist die Methode first! die gleiche wie die erste, löst aber ActiveRecord::RecordNotFound aus, wenn kein Datensatz gefunden wird. Beachten Sie, dass first! keine Argumente entgegennimmt.

Datei activerecord/lib/activerecord/relation/findermethods.rb, Zeile 128

def first!
first || raiserecordnotfoundexception!
end

Die Methode ActiveRecord::FinderMethods#first, die oben verwendet wird, sieht jedoch wie folgt aus:

Datei activerecord/lib/activerecord/relation/findermethods.rb, Zeile 116

def first(limit = nil)
checkreorderdeprecation unless loaded?

if Grenzwert
findnthwithlimit(0, limit)
sonst
findnth 0
end
end

Dank der obigen Beispiele sehen wir die Gefahr der Verwendung des ersteren. Wenn wir ActiveRecord::FinderMethods#find! verwenden und es wird kein passender Datensatz in der Datenbank gefunden, dann wird ActiveRecord::RecordNotFound zurückgegeben, was dazu führen kann, dass unser Programm nicht mehr funktioniert.

Wir müssen jedoch bedenken, dass dies nicht bedeutet, dass eine Methode ohne Ausrufezeichen am Ende sicher ist und keine Ausnahme auslöst oder den Empfänger ändert.

Ein neues Methodenpaar wurde in Ruby on Rails 6.0 eingeführt: ActiveRecord::Persistence::ClassMethods#insert_all und ActiveRecord::Persistence::ClassMethods#insert_all!

Die erste dieser Methoden birgt bereits ein gewisses Maß an Gefahr. Nun, laut der Dokumentation, fügen Siealle fügt mehrere Datensätze in die Datenbank mit einer einzigen SQL INSERT-Anweisung ein. Dabei werden weder Modelle instanziiert noch ActiveRecord-Callbacks oder Validierungen ausgelöst. Allerdings wird die Einfügungall! löst zusätzlich ActiveRecord::RecordNotUnique aus, wenn irgendwelche Zeilen einen eindeutigen Index der Tabelle verletzen. In diesem Fall werden keine Zeilen eingefügt. Das bedeutet, dass die erste dieser Methoden alle Datensätze mit Ausnahme derjenigen speichert, die den eindeutigen Index verletzen, während die zweite (gefährlichere) Methode eine Ausnahme auslöst und keinen der Datensätze in der Datenbank speichert.

3. Die Knallmethode hat eine Entsprechung ohne Ausrufezeichen

Viele Methoden, auch wenn sie kein Ausrufezeichen am Ende haben, sind gefährlich zu verwenden. Zum Beispiel ActiveRecord::FinderMethods#find. Laut Dokumentation wird ActiveRecord::RecordNotFound ausgelöst, wenn ein oder mehrere Datensätze für die angeforderten IDs nicht gefunden werden können.

Wir sehen, dass diese Methode zwar den gleichen Gefährdungsgrad wie ActiveRecord::FinderMethods#first! hat, aber kein Ausrufezeichen.

Das Gleiche gilt für die Änderung des Empfängers. Beispielsweise löscht Array.delete (wie dokumentiert) alle Elemente aus self, die mit object übereinstimmen, und gibt das letzte gelöschte Element zurück, oder nil, wenn keine übereinstimmenden Elemente gefunden werden.

 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

Sie können deutlich sehen, dass das Objekt geändert wurde. Die beiden Methoden haben gemeinsam, dass sie kein Ausrufezeichen-Äquivalent haben. Wenn also die Methode, die wir erstellen wollen, die oben erwähnten Gefahren mit sich bringt, muss sie nicht sofort ein Ausrufezeichen am Ende haben. Außerdem ist es ratsam, eine Bang-Methode zu erstellen, wenn es bereits eine Methode mit demselben Namen gibt, die weniger gefährlich ist als die Methode, die Sie erstellen möchten.

Wann sollte man Knallmethoden anwenden?

Man kann sich fragen, warum man diese gefährlichen Methoden überhaupt verwendet, zumal es normalerweise weniger gefährliche Gegenstücke gibt. Einer der Vorteile kann z. B. eine verbesserte Codeleistung dank der Verringerung der Anzahl der erstellten Objekte sein. Hier können Sie mehr über die Leistungssteigerung von Rails lesen.

Wenn es um das Auslösen von Ausnahmen geht, kann die Verwendung der create-Methode anstelle des gefährlichen create! zu einer Situation führen, in der ein Fehler in unserer Anwendung schwer zu erkennen ist, weil die Datensätze nicht in die Datenbank geschrieben werden. Wenn wir also sicher sind, dass die Parameter, die wir dieser Methode übergeben, korrekt sind, sollten wir die Methode create! verwenden, die eine Ausnahme auslöst, wenn der Datensatz aus irgendeinem Grund nicht in der Datenbank gespeichert wird.

Die Schlussfolgerung ist einfach und lautet wie folgt: Der umsichtige Einsatz solcher Methoden kann die Leistung und Qualität unseres Codes verbessern. Wir müssen jedoch immer daran denken, dass ihre unsachgemäße Verwendung die ordnungsgemäße Ausführung des Codes verhindern kann.

Wann Sie Ihre eigene Knallmethode entwickeln sollten

Wenn Sie eine eigene gefährliche Methode erstellen wollen, müssen Sie einen bestimmten Entscheidungsprozess durchlaufen. Zunächst stellt sich die Frage, ob es bereits eine Methode gibt, die denselben Namen trägt wie die Methode, die Sie erstellen möchten, aber weniger gefährlich ist. Sie können auch ein Methodenpaar erstellen, bei dem die eine Methode der anderen entspricht, nur gefährlicher ist.

Es hat keinen Sinn, eine Bang-Methode zu erstellen, wenn ihr Gegenstück ohne Ausrufezeichen nicht existiert. Es gibt Methoden, die gefährlich sind, weil sie das Objekt verändern oder eine Ausnahme auslösen, und die dennoch kein Ausrufezeichen am Ende des Namens haben. Eine Bang-Methode ohne Entsprechung würde einen Programmierer, der Ihren Code verwendet, verwirren. Diese Person wäre nicht in der Lage zu sagen, worin die Gefahr dieser Methode besteht und warum sie ein Ausrufezeichen am Ende ihres Namens verdient.

Zweitens sollten wir überlegen, um welche Art von Gefahren es sich handelt. Aus den obigen Beispielen können wir schließen, dass die häufigste Art der Gefahr die Änderung des Objekts selbst (statt der Erstellung seiner Kopie) oder das Auslösen einer Ausnahme ist. Natürlich ist dies keine Regel, sondern eher ein Ergebnis der Analyse der in Ruby und Ruby on Rails definierten Methoden. Betrachten wir zum Beispiel die Implementierung eines Methodenpaares, bei dem die Methode ohne die Ausrufezeichen würde den Datensatz in der Datenbank speichern, während die Methode mit dem Ausrufezeichen die Validierung dieses Datensatzes überspringen würde. In diesem Fall ist klar, wo die potenzielle Gefahr bei der Verwendung solcher Methoden liegt.

Zusammenfassung

Eine Zusammenfassung des Wissens über die Bang-Methoden führt zu folgenden Schlussfolgerungen: Die 1. Methode mit dem Ausrufezeichen hat eine weniger bedrohlich das Gegenstück ohne Ausrufezeichen, zweitens führt die Methode mit Ausrufezeichen eine gefährliche Aktion durch, z. B. verändert sie den Empfänger oder löst eine Ausnahme aus.

Zusammenfassend lässt sich sagen, dass das Verständnis des Konzepts der Knallmethoden in Rubinrot Software-Entwicklung kann Ihre Programmierkenntnisse erheblich verbessern und für mehr Klarheit in Ihrer Codebasis sorgen. Bang-Methoden, die durch ein Ausrufezeichen am Ende ihres Namens gekennzeichnet sind, weisen auf eine destruktive oder potenziell gefährliche Version einer Methode hin. Nach der Konvention ist die Knallgegenstück einer Methode ist mit Vorsicht zu genießen, da sie Objekte direkt verändern kann, ohne eine separate Kopie zu erstellen. Dies kann besonders nützlich sein, wenn es um veränderliche Objekte geht oder wenn die Leistungsoptimierung ein Anliegen ist. Bei der Verwendung von Bang-Methoden ist jedoch Vorsicht geboten, da sie unbeabsichtigte Folgen haben können, wenn sie nicht richtig gehandhabt werden. Es ist auch erwähnenswert, dass nicht alle Methoden eine Knallversionund ihr Vorhandensein sollte von Fall zu Fall geprüft werden. Wenn Sie wissen, wann und wie Sie Bang-Methoden erstellen, können Sie dieses leistungsstarke Werkzeug effektiv einsetzen und sauberen, effizienten Code schreiben, der Ihren spezifischen Anforderungen entspricht.