Akses default tidak membuat pengubah akses pribadi menjadi berlebihan.
Posisi desainer bahasa yang tercermin dalam tutorial resmi - Mengontrol Akses ke Anggota Kelas dan itu cukup jelas (untuk kenyamanan Anda, pernyataan yang relevan dalam kutipan dibuat tebal ):
Kiat Memilih Tingkat Akses:
Jika programmer lain menggunakan kelas Anda, Anda ingin memastikan bahwa kesalahan dari penyalahgunaan tidak dapat terjadi. Tingkat akses dapat membantu Anda melakukan ini.
- Gunakan tingkat akses paling ketat yang masuk akal untuk anggota tertentu. Gunakan pribadi kecuali Anda punya alasan kuat untuk tidak melakukannya.
- Hindari bidang publik kecuali konstanta. (Banyak contoh dalam tutorial menggunakan bidang publik. Ini dapat membantu menggambarkan beberapa poin secara ringkas, tetapi tidak disarankan untuk kode produksi.) Bidang publik cenderung menghubungkan Anda ke implementasi tertentu dan membatasi fleksibilitas Anda dalam mengubah kode Anda.
Daya tarik Anda terhadap testabilitas sebagai pembenaran untuk sepenuhnya menjatuhkan pengubah pribadi adalah salah, seperti dibuktikan misalnya dengan jawaban di New to TDD. Haruskah saya menghindari metode pribadi sekarang?
Tentu saja Anda dapat memiliki metode pribadi, dan tentu saja Anda dapat mengujinya.
Entah ada beberapa cara untuk mendapatkan metode swasta untuk menjalankan, dalam hal ini Anda dapat menguji seperti itu, atau ada tidak ada cara untuk mendapatkan swasta untuk menjalankan, dalam hal: mengapa sih yang Anda mencoba untuk menguji itu, hanya hapus saja ...
Posisi desainer bahasa pada tujuan dan penggunaan akses tingkat paket dijelaskan dalam tutorial resmi lain, Membuat dan Menggunakan Paket dan tidak ada kesamaan dengan ide menjatuhkan pengubah pribadi (untuk kenyamanan Anda, pernyataan yang relevan dalam kutipan dibuat tebal ) :
Anda harus menggabungkan kelas-kelas ini dan antarmuka dalam sebuah paket karena beberapa alasan, termasuk yang berikut:
- Anda dan pemrogram lainnya dapat dengan mudah menentukan bahwa jenis ini terkait ...
- Anda dapat mengizinkan tipe-tipe di dalam paket untuk memiliki akses tidak terbatas satu sama lain namun masih membatasi akses untuk tipe di luar paket ...
<Kata kasar "Kurasa aku sudah cukup banyak mendengar rengekan. Sepertinya sudah waktunya untuk mengatakan dengan keras dan jelas ...">
Metode pribadi bermanfaat untuk pengujian unit.
Catatan di bawah ini mengasumsikan bahwa Anda terbiasa dengan cakupan kode . Jika tidak, luangkan waktu untuk belajar, karena itu cukup berguna bagi mereka yang tertarik dalam pengujian unit dan pengujian sama sekali.
Baiklah, jadi saya punya metode pribadi dan tes unit, dan analisis cakupan memberi tahu saya bahwa ada celah, metode pribadi saya tidak dicakup oleh tes. Sekarang...
Apa yang saya peroleh dari merahasiakannya
Karena metode bersifat pribadi, satu-satunya cara untuk melanjutkan adalah mempelajari kode untuk mempelajari cara menggunakannya melalui API non-pribadi. Biasanya, penelitian semacam itu mengungkapkan bahwa alasan untuk kesenjangan adalah bahwa skenario penggunaan tertentu tidak ada dalam tes.
void nonPrivateMethod(boolean condition) {
if (condition) {
privateMethod();
}
// other code...
}
// unit tests don't invoke nonPrivateMethod(true)
// => privateMethod isn't covered.
Demi kelengkapan, alasan lain (kurang sering) untuk kesenjangan cakupan ini bisa berupa bug dalam spesifikasi / desain. Saya tidak akan terjun jauh ke sini di sini, untuk menjaga hal-hal sederhana; Cukuplah untuk mengatakan bahwa jika Anda melemahkan batasan akses "hanya untuk membuat metode dapat diuji", Anda akan kehilangan kesempatan untuk mengetahui bahwa bug ini ada sama sekali.
Baik, untuk memperbaiki kesenjangan, saya menambahkan unit test untuk skenario yang hilang, ulangi analisis cakupan dan verifikasi bahwa celah itu hilang. Apa yang saya miliki sekarang? Saya telah mendapatkan sebagai unit test baru untuk penggunaan khusus API non-pribadi.
Tes baru memastikan bahwa perilaku yang diharapkan untuk penggunaan ini tidak akan berubah tanpa pemberitahuan karena jika itu berubah, tes akan gagal.
Pembaca dari luar dapat melihat ke tes ini dan belajar bagaimana seharusnya menggunakan dan berperilaku (di sini, pembaca dari luar mencakup diri saya di masa depan, karena saya cenderung melupakan kode satu atau dua bulan setelah saya selesai dengan itu).
Tes baru toleran terhadap refactoring (apakah saya refactor metode pribadi? Anda bertaruh!) Apa pun yang saya lakukan privateMethod
, saya selalu ingin menguji nonPrivateMethod(true)
. Apa pun yang saya lakukan privateMethod
, tidak perlu memodifikasi tes karena metode tidak dipanggil secara langsung.
Tidak buruk? Anda bertaruh.
Apa yang saya lepas dari pelemahan batasan akses
Sekarang bayangkan bahwa alih-alih di atas, saya hanya memperlemah batasan akses. Saya melewatkan studi kode yang menggunakan metode dan melanjutkan langsung dengan tes yang memanggil saya exPrivateMethod
. Besar? Tidak!
Apakah saya mendapatkan tes untuk penggunaan khusus API non-pribadi yang disebutkan di atas? Tidak: tidak ada tes untuk nonPrivateMethod(true)
sebelumnya, dan tidak ada tes seperti itu sekarang.
Apakah pembaca luar mendapatkan kesempatan untuk lebih memahami penggunaan kelas? Tidak. "- Hei apa tujuan dari metode yang diuji di sini? - Lupakan saja, ini hanya untuk penggunaan internal. - Ups."
Apakah toleran terhadap refactoring? Tidak mungkin: apa pun yang saya ubah exPrivateMethod
, kemungkinan akan memecahkan tes. Ganti nama, gabungkan ke beberapa metode lain, ubah argumen dan pengujian hanya akan berhenti mengkompilasi. Sakit kepala? Anda bertaruh!
Kesimpulannya , bertahan dengan metode pribadi memberi saya peningkatan yang berguna, andal dalam unit test. Sebaliknya, melemahnya batasan akses "untuk testabilitas" hanya memberi saya kode tes yang tidak jelas dan sulit dipahami, yang juga beresiko permanen dipatahkan oleh refactoring minor; terus terang apa yang saya dapatkan tampak seperti utang teknis .
</rant>