Jangan mendeklarasikan antarmuka untuk objek yang tidak dapat diubah
[EDIT] Di mana objek yang dimaksud mewakili Data Transfer Objects (DTOs) atau Data Lama Biasa (PODs)
Apakah itu pedoman yang masuk akal?
Hingga kini, saya sering membuat antarmuka untuk kelas tersegel yang tidak dapat diubah (data tidak dapat diubah). Saya sudah mencoba berhati-hati untuk tidak menggunakan antarmuka di mana pun saya peduli tentang ketidakberubahan.
Sayangnya, antarmuka mulai meresapi kode (dan bukan hanya kode saya yang saya khawatirkan). Anda akhirnya lulus antarmuka, dan kemudian ingin meneruskannya ke beberapa kode yang benar-benar ingin mengasumsikan bahwa hal yang diteruskan ke itu tidak dapat diubah.
Karena masalah ini, saya mempertimbangkan untuk tidak pernah mendeklarasikan antarmuka untuk objek yang tidak dapat diubah.
Ini mungkin memiliki konsekuensi sehubungan dengan Unit Testing, tetapi selain itu, apakah ini tampak sebagai pedoman yang masuk akal?
Atau apakah ada pola lain yang harus saya gunakan untuk menghindari masalah "penyebaran antarmuka" yang saya lihat?
(Saya menggunakan objek yang tidak dapat diubah ini karena beberapa alasan: Terutama untuk keamanan utas karena saya menulis banyak kode multi-utas; tetapi juga karena itu berarti saya dapat menghindari membuat salinan defensif objek yang diteruskan ke metode. Kode menjadi lebih sederhana dalam banyak kasus ketika Anda mengetahui sesuatu tidak dapat diubah - yang tidak Anda lakukan jika Anda telah diberi antarmuka. Bahkan, seringkali Anda bahkan tidak dapat membuat salinan defensif dari objek yang dirujuk melalui antarmuka jika itu tidak memberikan operasi klon atau cara serialisasi ...)
[EDIT]
Untuk memberikan lebih banyak konteks karena alasan saya ingin membuat objek tidak berubah, lihat posting blog ini dari Eric Lippert:
http://blogs.msdn.com/b/ericlippert/archive/tags/immutability/
Saya juga harus menunjukkan bahwa saya sedang bekerja dengan beberapa konsep tingkat rendah di sini, seperti item yang sedang dimanipulasi / diedarkan dalam antrian pekerjaan multi-threaded. Ini pada dasarnya adalah DTO.
Juga Joshua Bloch merekomendasikan penggunaan benda-benda abadi dalam bukunya Java Efektif .
Mengikuti
Terima kasih atas umpan baliknya, semuanya. Saya telah memutuskan untuk terus maju dan menggunakan pedoman ini untuk DTO dan sejenisnya. Sejauh ini sudah bekerja dengan baik, tapi baru seminggu ... Tetap saja, ini terlihat bagus.
Ada beberapa masalah lain yang berkaitan dengan ini yang ingin saya tanyakan; terutama sesuatu yang saya sebut "Kerusakan Dalam atau Dangkal" (nomenklatur yang saya curi dari kloning Deep dan Dangkal) - tapi itu pertanyaan lain kali.
List<Number>
yang dapat menampung Integer
, Float
, Long
, BigDecimal
, dll ... Semua yang berubah sendiri.