Beberapa waktu yang lalu saya membaca semacam "aturan praktis" tentang konkret dari tipe parameter metode, tipe pengembalian dan tipe properti, tapi saya tidak ingat.
Itu mengatakan sesuatu tentang menjaga jenis pengembalian Anda sekonkret mungkin dan jenis parameter Anda seabstrak mungkin ... atau sebaliknya.
Saya tidak tahu apakah itu benar-benar saran yang baik atau buruk, jadi jika Anda memiliki pemikiran sendiri tentang hal itu, silakan beri komentar.
Bersulang.
Jawaban:
Tidak perlu lagi, janji tidak kurang.
Ungkapan tersebut muncul dari ide "Desain oleh Kontrak" yang dipelopori oleh Bertrand Meyer.
http://wiki3.cosc.canterbury.ac.nz/index.php/Design_by_contract
Juga lihat "prinsip substitusi Liskov"
/programming/56860/what-is-the-liskov-substitution-principle
Memiliki input abstrak dan output konkret membuat fungsi Anda lebih umum. Ini berarti dapat digunakan dengan lebih banyak cara. Di sisi lain, ini menempatkan kendala yang lebih kuat dari metode Anda, membatasi bagaimana implementasi di masa depan mungkin bekerja. Jadi itu adalah trade-off antara berbagai tujuan.
Bisa jadi Anda mendengar ekstrapolasi hukum Postel : "Jadilah konservatif dalam apa yang Anda kirim, liberal dalam apa yang Anda terima."
Sebagian besar tentang memaksimalkan penggunaan kembali kode. Sangat mudah untuk menemukan kasus untuk menunjukkan mengapa itu membantu. Pertimbangkan Java Iterable<T>sebagai contoh. Jika satu-satunya metode yang Anda lakukan adalah beralih melalui semua Ts, memiliki Iterable<T>tipe parameter Anda memungkinkan Anda untuk menggunakan metode itu dengan lebih dari 60 kelas bawaan, belum lagi kelas khusus yang mengimplementasikan antarmuka. Jika Anda membatasi, katakanlah, Vector<T>maka kode apa pun yang memanggil metode Anda harus dikonversi menjadi yang Vector<T>pertama.
Di sisi lain, mengembalikan suatu Iterable<T>dari metode membatasi jumlah kode yang dapat menggunakan nilai pengembalian Anda ke yang mengambil Iterable<T>parameter. Jika Anda kembali jenis yang sangat konkret, seperti Vector<T>, maka nilai Anda kembali dapat disahkan menjadi metode yang membutuhkan Serializable, Cloneable, Iterable<T>, Collection<T>, List<T>, RandomAccess, Vector<T>, AbstractList<T>, atau AbstractCollection<T>, dan itu akan bekerja seperti yang diharapkan.