Kiedy stosować def w Groovy?

23

Od jakiegoś czasu rozwijam się w Groovy i zastanawiam się, jak często powinienem używać dynamicznego rzutowania def? Mój współpracownik uważa, że powinniśmy go zawsze używać, ponieważ pomaga Groovy w jakiś sposób, którego nie rozumiem.

Obecnie, deklarując typy zwracane przez metody i argumenty, lubię celowo określać, które obiekty należy pobrać i wypluć (dla czytelności kodu i pochodzę z tła Java ma to dla mnie sens) przykład:

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

Więc myślę, że moje pytanie jest to tylko preferencja kiedy użyć deflub czy istnieje realne zaletą korzystania to cały czas? (Dodałem ostatni przykład, ponieważ czułem, że pasuje on do pytania jako realnej opcji dla Groovy)

code-quality groovy grails

— PJT
źródło

3

Zobacz tutaj, w co wierzy twój współpracownik: stackoverflow.com/questions/184002/… .

— Remigijus Pankevičius

Widziałem to pytanie i odpowiedź zanim zdecydowałem się zadać to pytanie. „Dobrą praktyką w przypadku większych skryptów jest zawsze używanie słowa kluczowego„ def ”, aby nie napotkać dziwnych problemów dotyczących zakresu lub ingerować w zmienne, których nie zamierzasz robić”. -Ted Naleid. Co wydaje mi się dobre, kiedy decyduję się na pominięcie dowolnego typu lub użycie def w skryptach, ale co z deklarowaniem typów zwracanych przez metody i typów argumentów? Jaka jest dobra praktyka?

— PJT,

1

OK, rozumiem teraz twój punkt widzenia. To pytanie o programowanie silnie typowane vs programowanie dynamiczne. Rodzaj dyskusji, której staram się unikać ze względu na nadchodzące wojny płomieni :)

— Remigijus Pankevičius

20

Jako dobrą praktykę programowania (nawet skryptowania) zawsze rozważ określenie określonego (choć niekoniecznie konkretnego) typu zmiennej. Używaj deftylko wtedy, gdy dla zmiennej nie ma określonego typu.

Ponieważ OP zna Javę, nie różni się niczym od określenia rodzaju Object(choć wydaje się, że istnieje niewielka różnica ). Odpowiedź na to pytanie nie będzie się zatem różnić od odpowiedzi na pytanie typu: „dlaczego nie zawsze używać tego Objecttypu w Javie?”

Bycie tak precyzyjnym w zakresie typów, jak to możliwe, zmniejsza ryzyko błędów, a nawet służy jako dokumentacja własna. Podczas gdy, jeśli ktoś celowo implementuje dynamiczną logikę, użycie defmoże mieć sens. To w rzeczywistości jedna z największych zalet Groovy; program można pisać dynamicznie lub statycznie, tak jak trzeba! Tylko nie pozwól, aby lenistwo było powodem do użycia def;-)

Np. Ta metoda ma sens w przypadku określonego typu argumentu i typu zwracanego:

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

podczas gdy ta metoda ma sens z typem 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
źródło

-1

Kiedykolwiek kod, który piszesz, będzie używany przez innych jako publiczny interfejs API, zawsze powinieneś faworyzować użycie silnego pisania, pomaga wzmocnić kontrakt, pozwala uniknąć pomyłek w pisaniu argumentów, daje lepszą dokumentację, a także pomaga IDE z uzupełnianiem kodu. Ilekroć kod służy wyłącznie do użytku, na przykład metod prywatnych, lub gdy IDE może łatwo wywnioskować typ, masz większą swobodę decydowania, kiedy wpisać, czy nie.

— ASKAR
źródło