Quand utiliser def dans Groovy?


23

Je développe dans Groovy depuis un petit moment maintenant et je me demande à quelle fréquence je devrais utiliser le casting dynamique def? Un de mes collègues pense que nous devrions toujours l'utiliser car cela aide Groovy d'une manière que je ne comprends pas.

Actuellement, lors de la déclaration des types de retour de méthode et des arguments, j'aime indiquer délibérément quels objets doivent être pris et recrachés (pour la lisibilité du code et je viens d'un arrière-plan Java, cela a du sens pour moi) exemple:

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

Donc, je suppose que ma question est juste une préférence de quand l'utiliser defou y a-t-il un réel avantage à l'utiliser tout le temps? (J'ai ajouté le dernier exemple parce que je sentais qu'il cadrait avec la question comme une option viable pour Groovy)


3
Voir ici ce en quoi votre collègue croit: stackoverflow.com/questions/184002/… .
Remigijus Pankevičius

J'ai vu cette question et cette réponse avant de décider de poser cette question. "La bonne pratique dans les scripts plus grands est de toujours utiliser le mot-clé" def "afin de ne pas rencontrer de problèmes d'étendue étranges ou d'interférer avec des variables que vous n'avez pas l'intention de". -Ted Naleid. Qu'est-ce qui me semble bien lorsque vous décidez d'omettre un type ou d'utiliser def dans des scripts, mais qu'en est-il de la déclaration des types de retour de méthode et des types d'argument? Qu'est-ce qu'une bonne pratique?
PJT

1
OK, je vois votre point maintenant. C'est une question sur la programmation fortement typée vs dynamique. Type de discussion que j'essaie d'éviter en raison de la guerre des flammes à venir :)
Remigijus Pankevičius

Réponses:


20

En tant que bonne pratique de programmation (même de script), pensez toujours à spécifier un type défini (mais pas nécessairement concret) pour une variable. À utiliser defuniquement s'il n'y a pas de type défini applicable à la variable.

Étant donné que l'OP connaît Java, ce n'est pas différent de spécifier un type de Object(bien qu'il semble y avoir une différence mineure ). La réponse à cette question ne sera donc pas différente de la réponse à une question comme: "pourquoi ne pas toujours utiliser le Objecttype en Java?"

Être aussi précis sur les types que possible réduit les risques de bogues et sert même d'auto-documentation. Alors que, si l'on met délibérément en œuvre une logique dynamique, l'utilisation defpeut avoir beaucoup de sens. C'est en fait l'une des plus grandes forces de Groovy; le programme peut être aussi typé dynamiquement ou statiquement qu'on en a besoin! Ne laissez pas la paresse être la raison de l'utilisation def;-)

Par exemple, cette méthode est logique avec un type d'argument défini et un type de retour:

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

alors que cette méthode est logique avec le type 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")
    }
}

-1

Chaque fois que le code que vous écrivez sera utilisé par d'autres en tant qu'API publique, vous devriez toujours favoriser l'utilisation d'une frappe forte, cela aide à renforcer le contrat, évite les éventuelles erreurs de type d'arguments passés, donne une meilleure documentation et aide également l'IDE avec complétion de code. Chaque fois que le code est pour votre usage uniquement, comme les méthodes privées, ou lorsque l'EDI peut facilement déduire le type, alors vous êtes plus libre de décider quand taper ou non.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.