Desarrollo de software con Ruby: Métodos Bang y formas de crearlos

A menudo nos encontramos con la afirmación de que el método bang es, en cierto sentido, un método peligroso y el signo de exclamación al final de su definición nos dice que estemos atentos cuando utilicemos este método. Veamos: ¿qué es exactamente esta amenaza cuando se trata de estos métodos y cuáles son sus características?

Características de los métodos bang

1. El método bang cambia el destinatario

Una de las características más populares de este tipo de métodos es que suelen cambiar de público. ¡Veamos como ejemplo el método map! Según la documentación, el método map! invoca el bloque dado una vez por cada elemento de self, sustituyendo el elemento por el valor devuelto por el bloque y si no se da ningún bloque, se devuelve en su lugar un Enumerador.

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

Como podemos ver, object_id permanece inalterado. Por lo tanto, el peligro de utilizar un método de este tipo parece obvio. Si en nuestro código utilizamos la variable arry en cualquier otro lugar, entonces el map! la cambiará. Esto puede hacer que nuestro programa funcione de una manera no deseada o incluso que se bloquee.

Hay objetos en Ruby que no pueden modificarse, como las instancias de las clases Integer, Float y Symbol. Mientras trabaja en un proyectoTambién puedes encontrarte con el llamado "comentario mágico", que dice así:

frozenstringliteral: true

Si se intentara cambiar el destinatario de la cadena en el código en el que se utilizó dicho comentario, se produciría un error como el siguiente:

¡ 'abc'.upcase!
 FrozenError (no se puede modificar la cadena congelada)

Curiosamente, había planes para introducir String inalterables en Rubí 3.0pero se decidió no introducir este cambio. Sin embargo, debe recordarse que no todos los métodos bang cambian el destinatario, por lo que siempre debe comprobarse en la documentación qué tipo de peligro debe esperarse en el caso de un método concreto.

2. El método bang lanza una excepción

Otra característica distintiva de estos métodos es que, para muchos de ellos, se lanza una excepción. ¡Un ejemplo de estos métodos es el método ActiveRecord::FinderMethods#first! De acuerdo con la documentación, el método first! es igual que el first pero lanza ActiveRecord::RecordNotFound si no se encuentra ningún registro. Tenga en cuenta que first! no acepta argumentos.

File activerecord/lib/activerecord/relation/findermethods.rb, line 128

¡def first!
¡first || raiserecordnotfoundexception!
end

Sin embargo, el método ActiveRecord::FinderMethods#first que se utiliza más arriba tiene el siguiente aspecto:

File activerecord/lib/activerecord/relation/findermethods.rb, line 116

def first(limit = nil)
checkreorderdeprecation unless loaded?

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

Gracias a los ejemplos anteriores, vemos el peligro de utilizar la primera opción. Si utilizamos ActiveRecord::FinderMethods#find! y no encuentra un registro adecuado en la base de datos, entonces devolverá ActiveRecord::RecordNotFound, lo que puede hacer que nuestro programa deje de funcionar.

Sin embargo, debemos recordar que esto no significa que si un método no tiene un signo de exclamación al final, es seguro y no lanzará la excepción o cambiará el destinatario.

En Ruby on Rails 6.0 se ha introducido un nuevo par de métodos: ActiveRecord::Persistence::ClassMethods#insert_all y ¡ActiveRecord::Persistence::ClassMethods#insert_all!

El primero de estos métodos ya muestra cierto grado de peligrosidad. Pues, según la documentación, insertarinserta múltiples registros en la base de datos en una única sentencia SQL INSERT. No instanciará ningún modelo ni activará devoluciones de llamada o validaciones de ActiveRecord. Sin embargo, la inserciónall! lanza adicionalmente ActiveRecord::RecordNotUnique si alguna fila viola un índice único de la tabla. En ese caso, no se insertará ninguna fila. Esto significa que el primero de estos métodos guardará todos los registros excepto los que infrinjan el índice único, mientras que el segundo método (más peligroso) lanzará una excepción y no guardará ninguno de los registros en la base de datos.

3. El método bang tiene un equivalente sin signo de exclamación

Muchos métodos, aunque no tengan un signo de exclamación al final, son peligrosos de utilizar. Por ejemplo, ActiveRecord::FinderMethods#find. Según la documentación, si no se pueden encontrar uno o más registros para los identificadores solicitados, se mostrará ActiveRecord::RecordNotFound.

Podemos ver que, aunque este método tiene el mismo grado de peligrosidad que ActiveRecord::FinderMethods#first!, no tiene un signo de exclamación.

Lo mismo ocurre cuando se trata de modificar el destinatario. Por ejemplo, Array.delete (como está documentado) borra todos los elementos del self que sean iguales a object y devuelve el último elemento borrado, o nil si no se encuentra ningún elemento coincidente.

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

Se puede ver claramente que el objeto ha sido modificado. Lo que los dos métodos tienen en común es que no tienen un signo de exclamación equivalente. Por lo tanto, si el método que deseamos crear tuviera el tipo de peligros que he mencionado anteriormente, no es necesario que tenga inmediatamente un signo de exclamación al final. Además, es aconsejable crear un método bang si ya existe un método con el mismo nombre que sea menos peligroso que el método que queremos crear.

Cuándo utilizar los métodos bang

Uno puede preguntarse por qué utilizar estos métodos peligrosos, sobre todo teniendo en cuenta que normalmente disponemos de homólogos menos peligrosos. Una de las ventajas puede ser, por ejemplo, la mejora del rendimiento del código gracias a la reducción del número de objetos creados. Aquí puedes leer más sobre cómo aumentar el rendimiento de Rails.

Cuando se trata de lanzar excepciones, utilizar el método create en lugar del peligroso create! puede llevarnos a una situación en la que un error en nuestra aplicación sea difícil de detectar porque los registros no se escribirán en la base de datos. Por lo tanto, si estamos seguros de que los parámetros que pasamos a este método son correctos, deberíamos utilizar el método create!, que lanzará una excepción si, por alguna razón, el registro no se guarda en la base de datos.

La conclusión es sencilla, y es la siguiente: el uso prudente de estos métodos puede mejorar el rendimiento y la calidad de nuestro código. Sin embargo, debemos recordar siempre que su uso inadecuado puede impedir que el código funcione correctamente.

Cuándo crear su propio método bang

Si quieres crear tu propio método peligroso, debes pasar por un cierto proceso de toma de decisiones. En primer lugar, la cuestión es si ya existe un método con el mismo nombre que el que quieres crear pero menos peligroso. También puedes plantearte crear un par de métodos en los que uno de ellos sea equivalente al otro, sólo que más peligroso.

No tiene sentido crear un método bang si no existe su homólogo sin signo de exclamación. Hay métodos que son peligrosos porque cambian el objeto o lanzan una excepción, y sin embargo no tienen un signo de exclamación al final del nombre. Crear un método bang sin equivalente confundiría a un programador que utilizara su código. Esta persona no sería capaz de decir cuál es el peligro de este método y por qué merece un signo de exclamación al final de su nombre.

En segundo lugar, debemos considerar de qué tipo de peligros estamos hablando. De los ejemplos anteriores, podemos concluir que el tipo de peligro más común es el cambio del propio objeto (en lugar de crear su copia) o el lanzamiento de una excepción. Por supuesto, esto no es una regla, sino el resultado de analizar los métodos que se han definido en Ruby y Ruby on Rails. Por ejemplo, podríamos considerar la implementación de un par de métodos en el que el método sin el parámetro signo de exclamación guardaría el registro en la base de datos, mientras que el método con el signo de exclamación omitiría la validación de este registro. En este caso, está claro dónde reside el peligro potencial de utilizar estos métodos.

Resumen

Un resumen del conocimiento de los métodos bang apunta a estas conclusiones: el 1er método con el signo de exclamación tiene un menos amenazante homólogo sin signo de exclamación, en segundo lugar, el método con signo de exclamación realiza una acción peligrosa, por ejemplo, modifica el destinatario o lanza una excepción.

En conclusión, comprender el concepto de métodos bang en Ruby desarrollo de software puede mejorar en gran medida sus habilidades de codificación y aportar más claridad a su base de código. Métodos Bang, denotados por un signo de exclamación al final de sus nombres, indican una versión destructiva o potencialmente peligrosa de un método. Por convención, el bang contraparte de un método debe utilizarse con precaución, ya que puede modificar objetos directamente, sin crear una copia separada. Esto puede ser particularmente útil cuando se trata de objetos mutables o cuando la optimización del rendimiento es una preocupación. Sin embargo, es importante tener cuidado al utilizar métodos bang, ya que pueden tener consecuencias no deseadas si no se manejan adecuadamente. También hay que tener en cuenta que no todos los métodos tienen una función versión bangy su presencia debe evaluarse caso por caso. Si sabes cuándo y cómo crear métodos bang, podrás utilizar esta potente herramienta con eficacia y escribir código limpio y eficiente que satisfaga tus requisitos específicos.