Berapa banyak baris per kelas yang terlalu banyak di Jawa? [Tutup]

Dalam pengalaman Anda, apa aturan praktis yang berguna untuk berapa banyak baris kode yang terlalu banyak untuk satu kelas di Jawa?

Untuk menjadi jelas, saya tahu bahwa jumlah baris bahkan tidak dekat dengan standar nyata untuk digunakan untuk apa yang seharusnya ada di kelas tertentu dan apa yang tidak boleh. Kelas harus dirancang sesuai dengan filosofi OOP yang tepat (enkapsulasi, dll.) Dalam pikiran. Yang mengatakan, aturan praktis dapat memberikan titik awal yang berguna untuk pertimbangan refactoring (yaitu "Hmmm, kelas ini memiliki> n baris kode; mungkin tidak dapat dibaca dan melakukan pekerjaan enkapsulasi yang buruk, jadi saya mungkin ingin melihat apakah harus refactored di beberapa titik ").

Di sisi lain, mungkin Anda pernah menemukan contoh kelas yang sangat besar yang masih mematuhi desain OOP dengan baik dan dapat dibaca dan dirawat meskipun panjangnya?

Inilah pertanyaan terkait, non-duplikat tentang baris per fungsi .

Beberapa metrik yang menarik:

            junit fitnesse testNG dan jdepend semut kucing jantan
            ----- -------- ------ --- ------- --- ------
maks 500 498 1450 355 668 2168 5457
berarti 64.0 77.6 62.7 95.3 128.8 215.9 261.6
min 4 6 4 10 20 3 12
sigma 75 76 110 78 129 261 369
file 90 632 1152 69 55 954 1468
total baris 5756 49063 72273 6575 7085 206001 384026

Saya menggunakan FitNesse sebagai patokan karena saya punya banyak hubungannya dengan menulisnya. Di FitNesse kelas rata-rata adalah 77 baris. Tidak ada yang lebih panjang dari 498 baris. Dan standar deviasi adalah 76 baris. Itu berarti bahwa sebagian besar kelas kurang dari 150 baris. Bahkan Tomcat, yang memiliki satu kelas lebih dari 5000 baris, memiliki sebagian besar kelas kurang dari 500 baris.

Mengingat ini, kita mungkin dapat menggunakan 200 baris sebagai pedoman yang baik untuk tetap di bawah.

Bagi saya, baris kode tidak relevan dalam konteks ini. Ini semua tentang sejumlah alasan berbeda saya akan datang ke kelas ini untuk mengubahnya.

Jika saya datang ke kelas ini ketika saya ingin mengubah aturan untuk memvalidasi Seseorang, saya tidak ingin datang ke kelas yang sama untuk mengubah aturan untuk memvalidasi suatu Pesanan, saya juga tidak ingin datang ke sini untuk mengubah tempat saya bertahanlah Seseorang.

Yang mengatakan, jika Anda bertujuan untuk itu maka Anda akan jarang menemukan kelas lebih dari 200 baris. Mereka akan terjadi, untuk alasan yang sah, tetapi mereka akan jarang. Jadi jika Anda mencari metrik bendera merah maka itu bukan tempat yang buruk untuk memulai; tapi jadikan itu pedoman, bukan aturan.

Saya minta maaf tetapi saya sangat terkejut bahwa banyak jawaban menyatakan bahwa "tidak terlalu penting". Sangat penting, berapa banyak garis yang ada di kelas. Mengapa? Pertimbangkan prinsip-prinsip ini dalam menulis kode Java yang baik ...

• Testabilitas
• Kohesi
• Kopel
• Dapat dimengerti

Kelas dengan banyak garis di dalamnya kemungkinan besar akan melanggar semua prinsip-prinsip itu.

Bagi mereka yang telah menyatakannya "tidak terlalu penting" ... betapa menyenangkannya bagi Anda untuk mencoba dan memahami kelas yang memiliki lebih dari 5000 baris di dalamnya? Atau, untuk memodifikasinya? Jika Anda mengatakan itu menyenangkan, Anda memiliki afinitas aneh terhadap rasa sakit ...

Saya akan mengatakan setiap kelas yang memiliki lebih dari 1000 baris di dalamnya setidaknya harus dipertanyakan bagaimana mereka mungkin melanggar prinsip-prinsip di atas dan mungkin diurai menjadi beberapa kelas "off-shoot".

Komentar saya didasarkan pada membaca dan mempelajari penulis seperti Martin Fowler, Joshua Bloch dan Misko Hevery. Mereka adalah sumber yang bagus untuk berkonsultasi untuk menulis kode Java yang baik.

Apakah orang berikutnya (yang mungkin Anda dalam beberapa tahun) mendukung dan berusaha untuk menulis kelas yang memiliki lebih sedikit daripada lebih banyak baris di dalamnya.

Itu tergantung pada kompleksitas, bukan jumlah garis. Saya telah menulis rutinitas bisu besar yang mudah dimengerti dan yang melakukan satu hal dengan tepat dan melakukannya dengan baik, tetapi berlanjut hingga ratusan baris. Saya telah menulis fungsi yang cukup singkat yang sulit dimengerti (dan debug).

Hal lain yang bisa Anda lihat adalah jumlah fungsi publik di kelas. Itu juga bisa menjadi tanda peringatan.

Saya tidak memiliki perhitungan yang baik, tetapi saya sarankan melihat beberapa kode yang layak yang melakukan hal-hal berguna di toko Anda, dan mendasarkannya pada hal itu. Tentu saja Anda harus melihat kelas terpanjang dan API terbesar.

Ada terlalu banyak baris kode jika kelas melakukan terlalu banyak hal berbeda. Pada dasarnya, jika Anda mengikuti prinsip Tanggung Jawab Tunggal untuk kelas, ada batas seberapa besar kelas akan tumbuh.

Mengenai batasan fisik yang dapat Anda miliki (sumber: Format file kelas Java5 ):

• 65.536 konstanta, antarmuka yang diterapkan, bidang, metode, dan atribut - masing-masing. CATATAN: Anda akan kehabisan ruang konstan sebelum Anda kehabisan setiap item lainnya. CATATAN 2: atribut adalah konstruk file kelas - jangan disamakan dengan marker '@Attribute' (mis. Info debug dan kode byte disimpan sebagai atribut terpisah untuk suatu metode).
• Setiap metode dapat 4GB (32 bit) dari kode byte yang dihasilkan. CATATAN: Versi Java sebelum 1.5 hanya dapat memiliki 64KB (16 bit) kode byte yang dihasilkan untuk setiap metode.

Singkatnya, file kelas bisa jauh lebih besar daripada yang dianggap berguna oleh siapa pun . Jika Anda tetap berpegang pada prinsip tanggung jawab tunggal, file kelas Anda akan berukuran tepat.

Jawaban yang benar adalah 42. Hanya bercanda.
Sebenarnya, garis maksimum yang disarankan per kelas adalah 2000 baris.

"Konvensi Kode Java" sejak 1999 telah menyatakannya seperti ini:
File yang lebih panjang dari 2000 baris rumit dan harus dihindari.

Setelah mengikuti konvensi Sun / Oracle Coding sejak Java ditemukan, saya telah menemukan aturan praktis pada baris per kelas menjadi masuk akal. 99% dari Kode Java Anda harus sesuai ... Dan jika lebih dari 2000, cukup masukkan TODO di bagian atas yang mengatakan bahwa kelas perlu dikerjakan.

Yang terburuk adalah kasus sebaliknya ketika programmer membuat terlalu banyak kelas kecil dengan hampir tidak ada fungsi nyata di setiap kelas. Mengabaikan saran untuk "Favor Composition", programmer membuat ratusan kelas turunan yang membuat model objek rumit yang jauh lebih buruk daripada masalah kelas besar (yang setidaknya biasanya menjaga fungsionalitas dengan nama kelas yang relevan).

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html#3043

Kode Bersih:

Kelas Harus Kecil!

Aturan kelas yang pertama adalah bahwa mereka harus kecil. Aturan kelas yang kedua adalah bahwa mereka harus lebih kecil dari itu. Tidak, kami tidak akan mengulangi teks yang sama persis dari bab Fungsi. Tetapi seperti halnya fungsi, yang lebih kecil adalah aturan utama dalam mendesain kelas. Seperti halnya fungsi, pertanyaan langsung kami selalu "Seberapa kecil?"

** Dengan fungsi, kami mengukur ukuran dengan menghitung garis fisik. Dengan kelas kami menggunakan ukuran yang berbeda. Kami menghitung tanggung jawab. **

Nama kelas harus menggambarkan tanggung jawab apa yang dipenuhinya. Bahkan, penamaan mungkin merupakan cara pertama untuk membantu menentukan ukuran kelas. Jika kita tidak bisa mendapatkan nama ringkas untuk suatu kelas, maka kemungkinan besar itu terlalu besar. Semakin jelas nama kelas, semakin besar kemungkinan tanggung jawabnya terlalu banyak. Misalnya, nama kelas termasuk kata musang seperti Processor atau Manager atau Super sering mengisyaratkan agregasi tanggung jawab yang disayangkan.

Kemudian:

• Pastikan metode Anda hanya melakukan satu hal.
• Kemudian pastikan kelas tidak memiliki terlalu banyak tanggung jawab.

Anda akan berakhir dengan kelas dengan ukuran yang dapat dikelola.

Jumlah garis adalah metrik yang cukup buruk untuk kualitas kelas. Bagi saya, saya suka melihat (seperti yang orang lain sebutkan) pada metode publik, serta properti terbuka untuk umum (saya kira getter / setter publik di Jawa). Jika saya harus menarik nomor keluar dari udara ketika mungkin menarik perhatian saya, saya akan mengatakan ketika ada lebih dari 10 masing-masing. Sungguh, jika lebih dari sekitar 5 properti atau metode, saya akan melihat dan sering menemukan cara untuk refactor, tetapi apa pun di atas 10 biasanya merupakan tanda peringatan bahwa ada sesuatu yang kemungkinan besar terpapar dengan buruk.

Ini percakapan lain sepenuhnya, tetapi metode pribadi dan bidang kurang dari bau untuk saya, jadi jika mereka berkontribusi banyak pada jumlah baris, maka saya mungkin tidak khawatir. Paling tidak, itu menunjukkan bahwa mungkin tidak ada beberapa pengontrol Tuhan memanipulasi objek dari jauh, yang merupakan masalah desain masalah yang cukup.

Coba gunakan metrik yang lebih baik.

Salah satu contoh adalah Metrik ABC . Ini lebih merupakan ukuran seberapa banyak pekerjaan yang dilakukan oleh kode daripada berapa banyak kode yang ada.

Setiap baris yang termasuk dalam domain masalah kelas Anda yang ditulis di luar kelas adalah satu baris terlalu sedikit dan satu terlalu banyak di kelas tempat kelas itu tinggal. Pikirkan kelas sebagai topik. Anda harus menutupinya. Sesingkat mungkin ideal tetapi jika dibutuhkan 500 garis, dibutuhkan 500 garis. Jika 100 dari baris tersebut membahas topik lain, mereka termasuk di tempat lain. Membagi subdomain yang lebih kecil di dalam kelas sebagai kelas interior masuk akal tetapi saya hanya akan mendefinisikan mereka di luar kelas jika mereka menggunakan di tempat lain.