1. Huruf pertama nama kelas harus menggunakan huruf kapital. Huruf pertama bidang, metode, dan objek (pegangan) harus menggunakan huruf kecil. Seperti semua pengidentifikasi, semua kata yang terkandung di dalamnya harus berdekatan, dengan huruf pertama dari kata di antaranya menggunakan huruf kapital. Misalnya:
Salin kode sebagai berikut: ThisIsAClassName
thisIsMethodOrFieldName
Jika karakter penginisialisasi konstan muncul dalam definisi, gunakan huruf besar pada semua huruf dalam pengidentifikasi tipe dasar akhir statis. Ini akan menandainya sebagai konstanta waktu kompilasi.
Paket Java adalah kasus khusus: semuanya menggunakan huruf kecil, bahkan kata tengahnya. Untuk nama ekstensi nama domain, seperti com, org, net atau edu, dll., semua harus menggunakan huruf kecil (ini juga salah satu perbedaan antara Java 1.1 dan Java 1.2).
2. Saat membuat kelas untuk penggunaan umum, harap gunakan "bentuk klasik" dan sertakan definisi elemen berikut:
Copy kode kodenya sebagai berikut:
sama dengan()
Kode hash()
keString()
clone()（implementasi Cloneable）
mengimplementasikan Serializable
3. Untuk setiap kelas yang Anda buat, pertimbangkan untuk menempatkan main(), yang berisi kode untuk menguji kelas tersebut. Untuk menggunakan kelas dari suatu proyek, kita tidak perlu menghapus kode pengujian. Jika ada perubahan apa pun, mudah untuk kembali ke pengujian. Kode ini juga berfungsi sebagai contoh cara menggunakan kelas.
4. Metode harus dirancang menjadi unit fungsional yang singkat, yang dapat digunakan untuk mendeskripsikan dan mengimplementasikan bagian antarmuka kelas yang terputus-putus. Idealnya, pendekatannya harus singkat dan langsung pada sasaran. Jika panjangnya besar, pertimbangkan untuk membaginya menjadi beberapa bagian yang lebih pendek. Melakukan hal ini juga memfasilitasi penggunaan kembali kode dalam suatu kelas (terkadang, metode harus berukuran sangat besar, namun metode tersebut tetap harus melakukan hal yang sama).
5. Saat merancang sebuah kelas, harap tempatkan diri Anda pada posisi pemrogram klien (metode penggunaan kelas harus sangat jelas). Kemudian, tempatkan diri Anda pada posisi orang yang mengelola kode tersebut (antisipasi jenis perubahan apa yang mungkin terjadi, dan pikirkan cara untuk membuatnya lebih sederhana).
6. Buatlah kelas sesingkat dan sesingkat mungkin, dan hanya selesaikan masalah tertentu. Berikut adalah beberapa saran untuk desain kelas:
1. Pernyataan peralihan yang kompleks: pertimbangkan untuk menggunakan mekanisme "polimorfik".
2. Sejumlah besar metode melibatkan operasi dengan tipe yang sangat berbeda: pertimbangkan untuk menggunakan beberapa kelas untuk mengimplementasikannya secara terpisah.
3. Banyak variabel anggota mempunyai karakteristik yang sangat berbeda: pertimbangkan untuk menggunakan beberapa kelas
7. Jadikan segala sesuatunya se-pribadi mungkin. Anda dapat membuat bagian dari perpustakaan menjadi "publik" (metode, kelas, bidang, dll.) sehingga tidak akan pernah bisa dikeluarkan. Jika Anda memaksakannya, hal ini dapat merusak kode orang lain yang sudah ada, memaksa mereka untuk menulis ulang dan mendesainnya. Jika Anda hanya mempublikasikan apa yang harus Anda publikasikan, Anda bebas mengubah apa pun. Dalam lingkungan multi-thread, privasi merupakan faktor yang sangat penting. Hanya bidang pribadi yang dapat dilindungi dari penggunaan yang tidak disinkronkan.
8. Waspada terhadap “sindrom benda raksasa”. Bagi beberapa pemula yang terbiasa berpikir pemrograman sekuensial dan baru mengenal bidang OOP, mereka sering kali suka menulis program eksekusi sekuensial terlebih dahulu, lalu menyematkannya ke dalam satu atau dua objek besar. Menurut prinsip pemrograman, objek harus mengekspresikan konsep aplikasi, bukan aplikasi itu sendiri.
9. Jika Anda harus melakukan pemrograman yang tidak sedap dipandang, Anda setidaknya harus memasukkan kode tersebut ke dalam kelas.
10. Setiap kali Anda menemukan bahwa kelas-kelas terintegrasi sangat erat, Anda perlu mempertimbangkan apakah akan menggunakan kelas internal untuk meningkatkan pekerjaan pengkodean dan pemeliharaan (lihat "Meningkatkan Kode dengan Kelas Internal" di Bab 14, Bagian 14.1.2).
11. Tambahkan komentar secermat mungkin dan gunakan sintaksis dokumen komentar javadoc untuk menghasilkan dokumentasi program Anda sendiri.
12. Hindari penggunaan "angka ajaib". Angka-angka ini sulit untuk dicocokkan dengan kode. Jika Anda perlu memodifikasinya di masa mendatang, niscaya akan menjadi mimpi buruk, karena Anda tidak tahu apakah "100" mengacu pada "ukuran array" atau "sesuatu yang lain". Oleh karena itu, kita harus membuat sebuah konstanta, memberinya nama yang meyakinkan dan deskriptif, dan menggunakan pengenal konstanta di seluruh program. Hal ini membuat program lebih mudah untuk dipahami dan dipelihara.
13. Jika menyangkut pembuat dan pengecualian, Anda biasanya ingin menampilkan kembali pengecualian apa pun yang tertangkap di pembuat jika hal itu menyebabkan pembuatan objek tersebut gagal. Dengan cara ini penelepon tidak akan terus berpikir bahwa objek telah dibuat dengan benar.
14. Setelah pemrogram klien selesai menggunakan objek, jika kelas Anda memerlukan pekerjaan pembersihan, pertimbangkan untuk menempatkan kode pembersihan dalam metode yang terdefinisi dengan baik, menggunakan nama seperti cleanup() untuk menunjukkan penggunaan Anda dengan jelas. Selain itu, bendera boolean dapat ditempatkan di dalam kelas untuk menunjukkan apakah objek telah dihapus. Dalam metode finalize() kelas, pastikan bahwa objek telah dihapus dan kelas yang mewarisi RuntimeException telah dibuang (jika belum), sehingga menunjukkan kesalahan pemrograman. Sebelum mengambil solusi seperti ini, pastikan finalize() berfungsi di sistem Anda (Anda mungkin perlu memanggil System.runFinalizersOnExit(true) untuk memastikan perilaku ini).
15. Dalam lingkup tertentu, jika suatu objek harus dibersihkan (tidak diproses oleh mekanisme pengumpulan sampah), silakan gunakan metode berikut: inisialisasi objek jika berhasil, segera masukkan blok coba yang berisi klausa akhirnya untuk memulai pekerjaan pembersihan; .
16. Jika Anda perlu mengganti (membatalkan) finalize() selama proses inisialisasi, harap ingat untuk memanggil super.finalize() (jika Object milik kelas super langsung kami, ini tidak perlu). Dalam proses penggantian finalize(), panggilan ke super.finalize() harus menjadi tindakan terakhir, bukan tindakan pertama, untuk memastikan bahwa komponen kelas dasar masih valid saat dibutuhkan.
17. Saat membuat koleksi objek berukuran tetap, pindahkan objek tersebut ke dalam array (terutama jika Anda berencana mengembalikan koleksi ini dari suatu metode). Dengan cara ini, kita dapat menikmati manfaat pemeriksaan tipe array pada waktu kompilasi. Selain itu, penerima array mungkin tidak perlu "melemparkan" objek ke dalam array untuk menggunakannya.
18. Cobalah untuk menggunakan antarmuka daripada kelas abstrak. Jika Anda tahu sesuatu akan menjadi kelas dasar, pilihan pertama Anda adalah mengubahnya menjadi antarmuka. Hanya ketika Anda harus menggunakan definisi metode atau variabel anggota, Anda perlu mengubahnya menjadi kelas abstrak. Antarmuka pada dasarnya menggambarkan apa yang ingin dilakukan klien, sementara kelas didedikasikan untuk (atau memungkinkan) detail implementasi spesifik.
19. Di dalam tukang bangunan, lakukan hanya usaha yang diperlukan untuk mengembalikan benda ke keadaan yang benar. Jika memungkinkan, hindari memanggil metode lain, karena metode tersebut mungkin akan diganti atau dibatalkan oleh metode lain, sehingga menghasilkan hasil yang tidak terduga selama proses pembangunan (lihat Bab 7 untuk rinciannya).
20. Objek tidak boleh sekadar menyimpan sejumlah data; perilakunya juga harus terdefinisi dengan baik.
21. Saat membuat kelas baru berdasarkan kelas yang sudah ada, silahkan pilih terlebih dahulu “Baru” atau “Buat”. Masalah ini hanya boleh dipertimbangkan jika persyaratan desain Anda sendiri harus diwariskan. Jika pewarisan digunakan ketika kreasi baru diperbolehkan, keseluruhan desain menjadi rumit dan tidak perlu.
22. Gunakan pewarisan dan cakupan metode untuk menyatakan perbedaan antar perilaku, dan gunakan bidang untuk menyatakan perbedaan antar keadaan. Contoh yang sangat ekstrim adalah merepresentasikan warna melalui pewarisan dari kelas yang berbeda, yang tentunya harus dihindari: gunakan bidang "warna" secara langsung.
23. Untuk menghindari masalah saat pemrograman, harap pastikan bahwa setiap nama hanya berhubungan dengan satu kelas di mana pun jalur kelas Anda menunjuk. Jika tidak, kompiler mungkin akan menemukan kelas lain dengan nama yang sama terlebih dahulu dan melaporkan pesan kesalahan. Jika Anda curiga mengalami masalah jalur kelas, coba cari file .class dengan nama yang sama di setiap titik awal jalur kelas.
24. Saat menggunakan "adaptor" peristiwa di Java 1.1 AWT, sangat mudah untuk menemukan jebakan. Jika metode adaptor diganti dan metode ejaannya tidak terlalu khusus, hasil akhirnya adalah menambahkan metode baru alih-alih mengganti metode yang sudah ada. Namun, karena ini sepenuhnya legal, Anda tidak akan mendapatkan pesan kesalahan apa pun dari kompiler atau sistem runtime, tetapi kode Anda akan berperilaku tidak semestinya.
25. Gunakan solusi desain yang masuk akal untuk menghilangkan "fungsi semu". Artinya, jika Anda hanya perlu membuat satu objek kelas, jangan batasi diri Anda pada aplikasi terlebih dahulu dan tambahkan komentar "buat hanya satu objek". Harap pertimbangkan untuk merangkumnya ke dalam bentuk "anak tunggal". Jika Anda memiliki banyak kode tersebar di program utama yang digunakan untuk membuat objek Anda sendiri, pertimbangkan untuk mengambil solusi kreatif untuk merangkum kode ini.
26. Berhati-hatilah terhadap "kelumpuhan karena analisis". Ingat, apa pun yang terjadi, Anda perlu memahami status keseluruhan proyek terlebih dahulu dan kemudian memeriksa detailnya. Karena Anda memahami situasi keseluruhan, Anda dapat dengan cepat mengenali beberapa faktor yang tidak diketahui dan mencegah diri Anda jatuh ke dalam "logika mati" saat memeriksa detailnya.
27. Berhati-hatilah terhadap "optimasi prematur". Jalankan dulu, pikirkan untuk menjadi lebih cepat nanti, tetapi optimalkan hanya jika perlu dan jika terbukti ada hambatan kinerja di beberapa bagian kode. Kecuali Anda menggunakan alat khusus untuk menganalisis kemacetan, Anda mungkin hanya membuang-buang waktu. Biaya implisit dari peningkatan kinerja adalah kode Anda menjadi lebih sulit untuk dipahami dan dipertahankan.
28. Ingat, Anda menghabiskan lebih banyak waktu untuk membaca kode daripada menulisnya. Desain yang jelas menghasilkan program yang mudah dipahami, namun komentar, penjelasan yang cermat, dan beberapa contoh sering kali sangat berharga. Mereka sangat penting, baik bagi diri Anda sendiri maupun bagi orang-orang yang mengikuti Anda. Jika Anda masih meragukan hal ini, bayangkan saja rasa frustrasi Anda saat mencoba mencari informasi berguna dalam dokumentasi Java online, dan Anda mungkin akan yakin.
29. Jika Anda merasa telah melakukan analisis, desain, atau implementasi yang baik, harap ubah sedikit perspektif berpikir Anda. Coba undang beberapa orang luar, tidak harus ahli, tapi orang-orang dari bagian lain perusahaan. Minta mereka untuk melihat pekerjaan Anda dengan pandangan yang benar-benar segar dan lihat apakah mereka dapat menemukan masalah yang tidak Anda sadari. Dengan mengadopsi metode ini, kita sering kali dapat mengidentifikasi beberapa masalah utama pada tahap yang paling sesuai untuk modifikasi, dan menghindari hilangnya uang dan tenaga akibat penyelesaian masalah setelah produk dirilis.
30. Desain yang bagus dapat memberikan keuntungan terbesar. Singkatnya, seringkali diperlukan waktu yang lama untuk menemukan solusi yang paling tepat terhadap suatu permasalahan. Namun begitu Anda menemukan metode yang tepat, pekerjaan Anda di masa depan akan jauh lebih mudah, dan Anda tidak perlu menanggung perjuangan yang menyakitkan selama berjam-jam, berhari-hari, atau berbulan-bulan. Kerja keras kita akan mendatangkan pahala yang sebesar-besarnya (bahkan tak terukur). Dan karena saya berusaha keras, akhirnya saya mendapatkan rencana desain yang bagus, dan sensasi kesuksesan juga mengasyikkan. Tahan godaan untuk terburu-buru menyelesaikan pekerjaan, yang sering kali tidak sepadan dengan usaha yang dilakukan.