¿Cuándo usar def en Groovy?

23

Llevo un tiempo desarrollando en Groovy y me pregunto con qué frecuencia debería utilizar el casting dinámico def. Un compañero de trabajo mío cree que deberíamos usarlo siempre, ya que ayuda a Groovy de alguna manera que no entiendo.

Actualmente, al declarar los tipos y argumentos de retorno de métodos, me gusta establecer deliberadamente qué objetos se deben incorporar y escupir (para facilitar la lectura del código y vengo de un fondo de Java, tiene sentido para mí) ejemplo:

String doSomething(String something){
    //code
}
// vs
def doSomething(def somthing){
    //code
}
// vs 
def doSomething(somthing){
    // code
}

Entonces, supongo que mi pregunta es solo una preferencia de cuándo usarlo defo ¿hay una ventaja real de usarlo todo el tiempo? (Agregué el último ejemplo porque sentí que encaja con la pregunta como una opción viable para Groovy)

code-quality groovy grails

— PJT
fuente

3

Vea aquí en qué cree su compañero de trabajo: stackoverflow.com/questions/184002/… .

— Remigijus Pankevičius

Vi esa pregunta y respuesta en realidad antes de decidir hacer esta pregunta. "Una buena práctica en los scripts más grandes es usar siempre la palabra clave" def "para no tener problemas de alcance extraños o interferir con variables que no tiene la intención". -Ted Naleid. Lo que me suena bien al decidir entre omitir cualquier tipo o usar def en los scripts, pero ¿qué hay de declarar los tipos de retorno de método y los tipos de argumento? ¿Qué es una buena práctica?

— PJT

1

Bien, ahora entiendo tu punto. Es una pregunta sobre programación fuertemente tipada vs dinámica. Tipo de discusión que trato de evitar debido a las guerras de llamas por delante :)

— Remigijus Pankevičius

20

Como buena práctica de programación (incluso scripting), siempre considere especificar un tipo definido (aunque no necesariamente concreto) para una variable. Use defsolo si no hay un tipo definido aplicable a la variable.

Dado que el OP conoce Java, no es diferente de especificar un tipo de Object(aunque parece haber una pequeña diferencia ). La respuesta a esta pregunta no será diferente de responder una pregunta como: "¿por qué no usar siempre el Objecttipo en Java?"

Ser tan definido sobre los tipos como sea posible reduce las posibilidades de errores e incluso sirve como documentación propia. Mientras que, si uno está implementando deliberadamente una lógica dinámica, usarlo defpodría tener mucho sentido. De hecho, esa es una de las mayores fortalezas de Groovy; ¡el programa puede ser tan dinámico o estático como se necesita! Simplemente no dejes que la pereza sea la razón para usar def;-)

Por ejemplo, este método tiene sentido con un tipo de argumento definido y un tipo de retorno:

// def val or Object val, opens up the possibility
// of the caller sending a non-numeric value 
Number half(Number val) {  
    val/2
}

mientras que este método tiene sentido con el tipo def

// I'd let them pass an argument of any type; 
// type `Object` makes sense too
def getIdProperty(def val) {   
    if(val?.hasProperty('id')) {
        // I don't know the type of this returned 
        // value and I don't really need to care 
        return val.id            
    }
    else {
        throw new IllegalArgumentException("Argument doesn't have an 'id' property")
    }
}

— Gaurav Thapa
fuente

-1

Cada vez que el código que está escribiendo será utilizado por otros como una API pública, siempre debe favorecer el uso de tipeo fuerte, ayuda a fortalecer el contrato, evita posibles errores de tipo de argumentos pasados, brinda una mejor documentación y también ayuda El IDE con la finalización del código. Siempre que el código sea solo para su uso, como métodos privados, o cuando el IDE pueda inferir fácilmente el tipo, entonces es más libre de decidir cuándo escribir o no.

— ASKAR
fuente