Jangan lakukan itu; itu akan terlalu rumit dan Anda tidak akan membutuhkannya
... adalah jawaban yang saya tulis di sini 2 tahun yang lalu. Sekarang, saya tidak begitu yakin; sebenarnya, dalam beberapa bulan terakhir saya mulai memigrasikan kode lama ke format ini, bukan karena saya tidak punya yang lebih baik untuk dilakukan tetapi karena saya benar-benar membutuhkannya untuk mengimplementasikan fitur baru atau mengubah yang sudah ada. Saya mengerti keengganan otomatis yang orang lain di sini telah melihat kode itu, tapi saya pikir ini adalah sesuatu yang pantas dipikirkan.
Manfaat
Manfaat utama adalah kemampuan untuk memodifikasi dan memperluas kode. Jika Anda menggunakan
class Point {
int x,y;
// other point operations
}
daripada hanya melewati beberapa bilangan bulat di sekitar - yang merupakan sesuatu yang, sayangnya, banyak antarmuka lakukan - maka jauh lebih mudah untuk kemudian menambahkan dimensi lain. Atau ubah tipenya menjadi double. Jika Anda menggunakan List<Author> authorsatau List<Person> authorsalih-alih List<String> authorsnanti menjadi lebih mudah untuk menambahkan lebih banyak informasi ke apa yang penulis wakili. Menulisnya seperti ini rasanya seperti saya menyatakan yang jelas, tetapi dalam praktiknya saya telah bersalah menggunakan string dengan cara ini berkali-kali sendiri, terutama dalam kasus di mana itu tidak jelas pada awalnya maka saya akan membutuhkan lebih dari Sebuah benang.
Saat ini saya sedang mencoba untuk memperbaiki daftar string yang saling terkait di seluruh kode saya karena saya memerlukan lebih banyak informasi di sana, dan saya merasakan sakitnya: \
Di luar itu, saya setuju dengan penulis blog bahwa itu membawa lebih banyak informasi semantik , sehingga memudahkan pembaca untuk mengerti. Sementara parameter sering diberi nama yang bermakna dan mendapatkan jalur dokumentasi khusus, ini sering tidak terjadi dengan bidang atau penduduk setempat.
Manfaat akhirnya adalah keamanan jenis , untuk alasan yang jelas, tetapi di mata saya itu adalah hal kecil di sini.
Kekurangannya
Butuh waktu lebih lama untuk menulis . Menulis kelas kecil cepat dan mudah tetapi tidak mudah, terutama jika Anda membutuhkan banyak kelas ini. Jika Anda mendapati diri Anda berhenti setiap 3 menit untuk menulis beberapa kelas pembungkus baru, itu juga dapat merusak konsentrasi Anda. Saya ingin berpikir, bagaimanapun, bahwa upaya ini biasanya hanya akan terjadi pada tahap pertama dari penulisan kode apa pun; Saya biasanya bisa mendapatkan ide yang cukup bagus dengan cepat tentang entitas apa yang perlu dilibatkan.
Ini bisa melibatkan banyak setter redundan (atau konstruksi) dan pengambil . Penulis blog memberikan contoh yang benar-benar jelek dari new Point(x(10), y(10))bukan new Point(10, 10), dan saya ingin menambahkan bahwa penggunaan juga mungkin melibatkan hal-hal seperti Math.max(p.x.get(), p.y.get())bukan Math.max(p.x, p.y). Dan kode panjang sering dianggap lebih sulit untuk dibaca, dan memang begitu. Tetapi dalam semua kejujuran, saya punya perasaan banyak kode bergerak objek di sekitar, dan hanya metode tertentu yang membuatnya, dan bahkan lebih sedikit membutuhkan akses ke rincian berpasir nya (yang bukan OOPy toh).
Belum pasti
Saya akan mengatakan apakah ini membantu keterbacaan kode masih bisa diperdebatkan. Ya, lebih banyak informasi semantik, tetapi kode lebih panjang. Ya, lebih mudah untuk memahami peran masing-masing lokal, tetapi lebih sulit untuk memahami apa yang dapat Anda lakukan dengannya kecuali Anda pergi dan membaca dokumentasinya.
Seperti sebagian besar sekolah pemikiran lain, saya pikir tidak sehat untuk mengambil yang satu ini secara ekstrem. Saya tidak melihat diri saya pernah memisahkan koordinat x dan y untuk masing-masing dari tipe yang berbeda. Saya pikir Countitu tidak perlu ketika intharus mencukupi. Saya tidak suka unsigned intpenggunaan dalam C - sementara secara teori bagus, itu tidak memberi Anda informasi yang cukup, dan tidak melarang memperluas kode Anda nanti untuk mendukung -1 ajaib itu. Terkadang Anda memang membutuhkan kesederhanaan.
Saya pikir posting blog itu sedikit di sisi ekstrim. Tetapi secara keseluruhan, saya telah belajar dari pengalaman yang menyakitkan bahwa ide dasar di baliknya dibuat dari hal-hal yang benar.
Saya tidak menyukai kode over-engineered. Saya benar-benar melakukannya. Tetapi digunakan dengan benar, saya tidak berpikir ini over-engineering.