documentacion docs groovy closures

groovy - docs - grails 2.5 6



Groovy: cierres o métodos (2)

Tengo el hábito de utilizar Closures donde puedo en lugar de los métodos habituales, incluso cuando no necesito acceder a las variables gratuitas. Entonces, usaré esto:

def addNumbers = { left, right -> left + right }

.. en lugar de esto:

def addNumbers (left,right) { left + right }

¿Es esta mala práctica? Prefiero mucho más poder que obtengo cuando uso cierres sobre métodos, y prefiero la sintaxis.

¡Gracias!


Si bien todas las cosas que dice @Don son ciertas, no sé si alguna de ellas es tan significativa. Puede anular al delegado de un cierre que puede cambiar la ejecución, pero a menos que esté pasando el cierre (lo cual no se puede hacer con un método de todos modos), realmente no tiene que preocuparse por ninguna de esas cosas. Jugar con el delegado es una característica, no una responsabilidad.

En cuanto a un posible golpe de rendimiento de archivos de clase extra, ¿por qué estás usando Groovy si estás preocupado por el rendimiento?

Mi opinión es que realmente no importa. Si tiene mucha gente en su equipo que son desarrolladores antiguos de Java, probablemente le desagraden cuando usa cierres en los que un método funcionará. Por otro lado, alguien con fluidez en Groovy se molestará si desordena todo con métodos cuando un cierre tiene más sentido.

tl; dr - No hay una regla dura y rápida, en su lugar debe ejercer su buen juicio con la vista puesta en la legibilidad del código.


Solo uso cierres donde los necesito, es decir, uso métodos por defecto. Yo hago esto porque

  • Los métodos son más simples que los cierres. Los cierres tienen un delegado, un propietario, retienen el acceso a las variables que estaban en su ámbito local cuando se crean (lo que usted llama "variables libres"). Por defecto, las llamadas a métodos dentro de un cierre se resuelven de la siguiente manera:

    1. Cierre en sí
    2. Propietario del cierre
    3. Delegado de clausura

Pero este orden se puede cambiar en tiempo de ejecución, y el delegado de un cierre también se puede cambiar a cualquier objeto.

Todos estos factores combinados pueden hacer que algún código que use cierres sea muy difícil de asimilar, por lo que si no necesitas ninguno de esta complejidad, prefiero eliminarlo usando un método en su lugar.

  • Se genera un archivo .class para cada cierre definido en Groovy. Tengo exactamente cero evidencia para respaldar una afirmación de que un método regular es más eficaz que un cierre, pero tengo sospechas. Por lo menos, muchas clases pueden hacer que se quede sin espacio de memoria PermGen, esto solía sucederme con frecuencia hasta que eleve mi espacio PermGen a aproximadamente 200 MB.

No tengo idea de si la práctica que defiendo (utilizar métodos por defecto y cierres solo cuando los necesita) es ampliamente considerada como una "mejor práctica", por lo que tengo curiosidad por escuchar lo que otros piensan.