Développement de logiciels Ruby : Les méthodes Bang et les moyens de les créer

Il arrive souvent que l'on entende dire que la méthode bang est en quelque sorte une méthode dangereuse et que le point d'exclamation à la fin de sa définition nous incite à être vigilants lors de l'utilisation de cette méthode. Voyons ce qu'il en est : qu'est-ce que cette menace exactement en ce qui concerne ces méthodes et quelles sont leurs caractéristiques ?

Caractéristiques des méthodes bang

1. La méthode bang change le destinataire

L'une des caractéristiques les plus populaires de ces types de méthodes est qu'elles changent généralement de public. Prenons l'exemple de la méthode map ! D'après la documentation, la méthode map ! invoque le bloc donné une fois pour chaque élément de self, en remplaçant l'élément par la valeur renvoyée par le bloc et, si aucun bloc n'est donné, un énumérateur est renvoyé à la place.

 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

Comme nous pouvons le constater, l'identifiant de l'objet reste inchangé. Le danger d'utiliser une telle méthode semble donc évident. Si dans notre code nous avons utilisé la variable arry à un autre endroit, alors la carte ! la modifiera. Cela peut conduire à un fonctionnement indésirable de notre programme, voire à un plantage.

Il y a des objets dans Rubis qui ne peuvent pas être modifiées, telles que les instances des classes Integer, Float et Symbol. Lorsque vous travaillez sur un projetVous pouvez également rencontrer ce que l'on appelle le commentaire magique, qui se présente comme suit :

frozenstringliteral : true

Si l'on tente de modifier le destinataire de la chaîne dans le code où un tel commentaire a été utilisé, on obtient une erreur de ce type :

 'abc'.upcase !
 FrozenError (ne peut pas modifier une chaîne gelée)

Il est intéressant de noter qu'il a été envisagé d'introduire une chaîne immuable en Ruby 3.0mais il a été décidé de ne pas procéder à cette modification. Toutefois, il convient de rappeler que toutes les méthodes bang ne modifient pas le destinataire, et qu'il faut donc toujours vérifier dans la documentation le type de danger auquel il faut s'attendre dans le cas d'une méthode particulière.

2. La méthode bang soulève une exception

Une autre caractéristique de ces méthodes est que, pour beaucoup d'entre elles, une exception est levée. Un exemple d'une telle méthode est la méthode ActiveRecord::FinderMethods#first ! D'après la documentation, la méthode first ! est identique à la méthode first mais lève ActiveRecord::RecordNotFound si aucun enregistrement n'est trouvé. Notez que first ! n'accepte aucun argument.

Fichier activerecord/lib/activerecord/relation/findermethods.rb, ligne 128

def first !
first || raiserecordnotfoundexception !
end

Cependant, la méthode ActiveRecord::FinderMethods#first utilisée ci-dessus ressemble à ceci :

Fichier activerecord/lib/activerecord/relation/findermethods.rb, ligne 116

def first(limit = nil)
checkreorderdeprecation unless loaded ?

if limit
findnthwithlimit(0, limit)
else
0 pour le nombre d'habitants
fin
fin

En remerciant les exemples ci-dessus, nous voyons le danger d'utiliser le premier. Si nous utilisons ActiveRecord::FinderMethods#find ! et qu'il ne trouve pas d'enregistrement approprié dans la base de données, il renverra ActiveRecord::RecordNotFound, ce qui peut entraîner l'arrêt de notre programme.

Cependant, nous devons nous rappeler que cela ne signifie pas que si une méthode n'a pas de point d'exclamation à la fin, elle est sûre et ne soulèvera pas d'exception ou ne changera pas de destinataire.

Une nouvelle paire de méthodes a été introduite dans Ruby on Rails 6.0 : ActiveRecord::Persistence::ClassMethods#insert_all et ActiveRecord::Persistence::ClassMethods#insert_all !

La première de ces méthodes présente déjà un certain degré de danger. En effet, selon la documentation, l'insertioninsère plusieurs enregistrements dans la base de données en une seule instruction SQL INSERT. Elle n'instancie aucun modèle et ne déclenche aucun rappel ou validation ActiveRecord. Cependant, l'instruction INSERTall ! lève également ActiveRecord::RecordNotUnique si des lignes ne respectent pas un index unique sur la table. Dans ce cas, aucune ligne n'est insérée. Cela signifie que la première de ces méthodes enregistrera tous les enregistrements à l'exception de ceux qui ne respectent pas l'index unique, tandis que la seconde (plus dangereuse) lèvera une exception et n'enregistrera aucun des enregistrements dans la base de données.

3. La méthode bang a un équivalent sans point d'exclamation

De nombreuses méthodes, même si elles n'ont pas de point d'exclamation à la fin, sont dangereuses à utiliser. Par exemple, ActiveRecord::FinderMethods#find. D'après la documentation Si un ou plusieurs enregistrements ne peuvent être trouvés pour les identifiants demandés, la méthode ActiveRecord::RecordNotFound sera levée.

Nous constatons que, bien que cette méthode présente le même degré de dangerosité que ActiveRecord::FinderMethods#first !, elle ne comporte pas de point d'exclamation.

Il en va de même lorsqu'il s'agit de modifier le destinataire. Par exemple, Array.delete (tel que documenté) supprime tous les éléments du self qui sont égaux à object et renvoie le dernier élément supprimé, ou nil si aucun élément correspondant n'est trouvé.

 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

On voit clairement que l'objet a été modifié. Les deux méthodes ont en commun de ne pas avoir d'équivalent en point d'exclamation. Par conséquent, si la méthode que nous souhaitons créer présente le genre de dangers que j'ai mentionnés plus haut, il n'est pas nécessaire qu'elle ait immédiatement un point d'exclamation à la fin. De plus, il est conseillé de créer une méthode bang s'il existe déjà une méthode du même nom qui est moins dangereuse que celle que l'on veut créer.

Quand utiliser les méthodes bang

On peut se demander pourquoi utiliser ces méthodes dangereuses, d'autant plus que nous avons généralement des équivalents moins dangereux. L'un des avantages peut être, par exemple, l'amélioration des performances du code grâce à la réduction du nombre d'objets créés. Pour en savoir plus sur l'amélioration des performances de Rails, cliquez ici..

En ce qui concerne la levée des exceptions, l'utilisation de la méthode create au lieu de la dangereuse méthode create ! peut conduire à une situation où une erreur dans notre application est difficile à détecter parce que les enregistrements ne seront pas écrits dans la base de données. Par conséquent, si nous sommes sûrs que les paramètres que nous transmettons à cette méthode sont corrects, nous devrions utiliser la méthode create !, qui lèvera une exception si, pour une raison quelconque, l'enregistrement n'est pas sauvegardé dans la base de données.

La conclusion est simple : une utilisation prudente de ces méthodes peut améliorer les performances et la qualité de notre code. Cependant, nous devons toujours garder à l'esprit que leur utilisation inappropriée peut empêcher le code de fonctionner correctement.

Quand créer sa propre méthode bang

Si vous souhaitez créer votre propre méthode dangereuse, vous devez suivre un certain processus de décision. Tout d'abord, la question est de savoir s'il existe déjà une méthode portant le même nom que celle que vous voulez créer, mais moins dangereuse. Vous pouvez également envisager de créer une paire de méthodes dont l'une est équivalente à l'autre, mais plus dangereuse.

Il est inutile de créer une méthode bang si son équivalent sans point d'exclamation n'existe pas. Il existe des méthodes qui sont dangereuses parce qu'elles modifient l'objet ou soulèvent une exception, et pourtant elles n'ont pas de point d'exclamation à la fin de leur nom. La création d'une méthode bang sans équivalent perturberait un programmeur qui utiliserait votre code. Celui-ci ne serait pas en mesure de dire quel est le danger de cette méthode et pourquoi elle mérite un point d'exclamation à la fin de son nom.

Deuxièmement, nous devons nous demander de quel type de danger nous parlons. D'après les exemples ci-dessus, nous pouvons conclure que le type de danger le plus courant est la modification de l'objet lui-même (au lieu de créer sa copie) ou la levée d'une exception. Bien entendu, il ne s'agit pas d'une règle mais plutôt du résultat de l'analyse des méthodes définies dans Ruby et Ruby on Rails. Par exemple, on peut considérer l'implémentation d'une paire de méthodes dans laquelle la méthode sans l'élément point d'exclamation enregistrerait l'enregistrement dans la base de données, tandis que la méthode avec le point d'exclamation ignorerait la validation de cet enregistrement. Dans ce cas, on voit clairement où se situe le danger potentiel de l'utilisation de ces méthodes.

Résumé

Un résumé de la connaissance des méthodes bang permet de tirer les conclusions suivantes : la 1ère méthode avec le point d'exclamation a une moins menaçante sans point d'exclamation, deuxièmement, la méthode avec un point d'exclamation effectue une action dangereuse, par exemple, modifie le destinataire ou soulève une exception.

En conclusion, la compréhension du concept de méthodes bang en Rubis développement de logiciels peut grandement améliorer vos compétences en matière de codage et apporter plus de clarté à votre base de code. Méthodes BangLes méthodes d'exécution, désignées par un point d'exclamation à la fin de leur nom, indiquent une version destructive ou potentiellement dangereuse d'une méthode. Par convention, le point d'exclamation contrepartie de bang d'une méthode doit être utilisée avec précaution, car elle peut modifier les objets directement, sans créer de copie séparée. Cela peut s'avérer particulièrement utile lorsqu'il s'agit d'objets mutables ou lorsque l'optimisation des performances est une préoccupation. Cependant, il est important de faire preuve de prudence lors de l'utilisation de méthodes bang, car elles peuvent avoir des conséquences inattendues si elles ne sont pas correctement gérées. Il convient également de noter que toutes les méthodes ne disposent pas d'une fonction version banget leur présence doit être évaluée au cas par cas. En sachant quand et comment créer des méthodes bang, vous pouvez utiliser cet outil puissant de manière efficace et écrire un code propre et efficace qui réponde à vos besoins spécifiques.