Когда использовать def в Groovy?


23

Я уже некоторое время занимаюсь разработкой в ​​Groovy, и мне интересно, как часто мне следует использовать динамическое приведение def? Мой коллега считает, что мы должны использовать его всегда, так как это помогает Groovy каким-то образом, я не понимаю.

В настоящее время, когда я объявляю методы, возвращающие типы и аргументы, мне нравится сознательно указывать, какие объекты следует принимать и выплевывать (для удобства чтения кода, и я пришел из Java-фона, это имеет смысл для меня), например:

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

Поэтому я думаю, что мой вопрос - это просто предпочтение того, когда использовать, defили есть реальное преимущество в том, чтобы использовать его постоянно? (Я добавил последний пример, потому что мне показалось, что он подходит для вопроса как жизнеспособного варианта для Groovy)


3
Посмотрите, во что верит ваш коллега: stackoverflow.com/questions/184002/… .
Ремигиюс Панкявичюс

Я видел этот вопрос и ответ на самом деле, прежде чем я решил задать этот вопрос. «Хорошая практика в больших сценариях - всегда использовать ключевое слово« def », чтобы вы не сталкивались со странными проблемами с областями видимости и не вмешивались в переменные, которые вам не нужны». Тед Нейлид. Что звучит хорошо для меня, когда я выбираю пропустить любой тип или использовать def в скриптах, но как насчет объявления типов возвращаемых методов и типов аргументов? Что такое хорошая практика?
PJT

1
Хорошо, теперь я понимаю вашу точку зрения. Это вопрос о строго типизированном и динамическом программировании. Тип обсуждения, которого я стараюсь избегать из-за предстоящих
огненных

Ответы:


20

В качестве хорошей практики программирования (даже написания сценариев) всегда рассматривайте возможность указания определенного (хотя и не обязательно конкретного) типа для переменной. Используйте defтолько если нет определенного типа, применимого к переменной.

Поскольку OP знает Java, он ничем не отличается от указания типа Object(хотя, кажется, есть небольшая разница ). Тогда ответ на этот вопрос не будет отличаться от ответа на вопрос типа «почему не всегда использовать Objectтип в Java?»

Быть как можно более определенным в отношении типов снижает вероятность ошибок и даже служит самодокументированием. Принимая во внимание, что если кто-то намеренно реализует динамическую логику, тогда использование defможет иметь большой смысл. Это на самом деле одна из самых сильных сторон Groovy; программа может быть динамически или статически типизирована так, как это необходимо! Только не позволяйте лени быть причиной для использования def;-)

Например, этот метод имеет смысл с определенным типом аргумента и типом возвращаемого значения:

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

в то время как этот метод имеет смысл с типом 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

Всякий раз, когда код, который вы пишете, будет использоваться другими в качестве общедоступного API, вы всегда должны отдавать предпочтение использованию строгой типизации, это помогает укрепить контракт, позволяет избежать возможных ошибок ввода аргументов, дает лучшую документацию, а также помогает IDE с дополнением кода. Всякий раз, когда код предназначен только для вашего использования, например, частные методы, или когда среда IDE может легко определить тип, вы можете более свободно решать, когда печатать или нет.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.