Kapan menggunakan def di Groovy?


23

Saya telah mengembangkan di Groovy untuk sementara waktu sekarang dan saya bertanya-tanya seberapa sering saya harus menggunakan casting dinamis def? Seorang rekan kerja saya percaya kita harus selalu menggunakannya karena itu membantu Groovy dalam beberapa hal yang saya tidak mengerti.

Saat ini, ketika mendeklarasikan metode mengembalikan tipe dan argumen, saya suka menyatakan dengan sengaja objek mana yang harus diambil dan dimuntahkan (untuk keterbacaan kode dan saya berasal dari latar belakang Java, masuk akal bagi saya) contoh:

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

Jadi saya kira pertanyaan saya apakah ini hanya pilihan kapan akan digunakan defatau adakah keuntungan nyata untuk menggunakannya sepanjang waktu? (Saya menambahkan contoh terakhir karena saya merasa cocok dengan pertanyaan sebagai pilihan yang layak untuk Groovy)


3
Lihat di sini apa yang diyakini rekan kerja Anda: stackoverflow.com/questions/184002/… .
Remigijus Pankevičius

Saya melihat pertanyaan dan jawaban itu sebelum saya memutuskan untuk mengajukan pertanyaan ini. "Praktik yang baik dalam skrip yang lebih besar adalah selalu menggunakan kata kunci" def "sehingga Anda tidak mengalami masalah pelingkupan yang aneh atau mengganggu variabel yang tidak Anda inginkan." -Ted Naleid. Yang kedengarannya bagus bagi saya ketika memutuskan antara menghilangkan semua jenis atau menggunakan def dalam skrip, tetapi bagaimana dengan mendeklarasikan metode mengembalikan tipe dan tipe argumen? Apa itu praktik yang baik?
PJT

1
Oke, saya mengerti maksud Anda sekarang. Ini pertanyaan tentang pemrograman dinamis sangat diketik vs dinamis. Jenis diskusi yang saya coba hindari karena nyala api di depan :)
Remigijus Pankevičius

Jawaban:


20

Sebagai praktik pemrograman yang baik (bahkan scripting), selalu pertimbangkan untuk menentukan tipe tertentu (walaupun tidak harus nyata) untuk suatu variabel. Gunakan defhanya jika tidak ada tipe pasti yang berlaku untuk variabel.

Karena OP tahu Java, tidak ada bedanya dengan menentukan jenis Object(meskipun tampaknya ada perbedaan kecil ). Maka jawaban untuk pertanyaan ini tidak akan berbeda dari menjawab pertanyaan seperti: "mengapa tidak selalu menggunakan Objecttipe di Jawa?"

Menjadi pasti tentang jenis mungkin mengurangi kemungkinan bug, dan bahkan berfungsi sebagai dokumentasi diri. Padahal, jika seseorang sengaja mengimplementasikan logika dinamis, maka menggunakan defmungkin masuk akal. Itu sebenarnya salah satu kekuatan terbesar Groovy; program dapat diketik secara dinamis atau statis seperti yang dibutuhkan! Hanya saja, jangan biarkan kemalasan menjadi alasan untuk menggunakan def;-)

Misalnya metode ini masuk akal dengan tipe argumen yang pasti dan jenis kembali:

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

sementara metode ini masuk akal dengan tipe 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

Setiap kali kode yang Anda tulis akan digunakan oleh orang lain sebagai API publik, Anda harus selalu mendukung penggunaan pengetikan yang kuat, ini membantu membuat kontrak lebih kuat, menghindari kemungkinan kesalahan ketik argumen yang dilewati, memberikan dokumentasi yang lebih baik, dan juga membantu IDE dengan penyelesaian kode. Setiap kali kode hanya untuk Anda gunakan, seperti metode pribadi, atau ketika IDE dapat dengan mudah menyimpulkan jenisnya, maka Anda lebih bebas untuk memutuskan kapan mengetik atau tidak.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.