Berapa batasan jumlah metode kelas?

Dalam buku desain berbeda yang saya baca, terkadang penekanan besar diberikan pada sejumlah metode yang harus dimiliki suatu kelas (mempertimbangkan bahasa OO, sebagai java atau C # misalnya). Seringkali contoh-contoh yang dilaporkan dalam buku-buku itu sangat rapi dan sederhana, tetapi jarang yang mencakup kasus "serius" atau kompleks.
Namun kisarannya berkisar antara 5 dan 8.

Dalam sebuah proyek saya mengembangkan kelas "Note", dengan atributnya sebagai properti: Judul, Desctiption, CreateDate, dll.
Kemudian beberapa metode dasar seperti: getRelations (jika catatan ditugaskan ke dokumen yang berbeda), getExpiryDate, dll.

Namun melanjutkan pengembangan aplikasi, lebih banyak fungsi diperlukan, dan, karena itu, lebih banyak metode.

Saya tahu bahwa semakin sedikit metode yang dimiliki sebuah kelas, semakin longgar pula itu. Itu memang keuntungan yang baik dalam hal modularitas dan usabilitas, ditambah lebih mudah untuk diedit.
Ngomong-ngomong jika dalam konteks kita tidak perlu (atau bahkan akal) untuk membuat sub-kelas dan semua fungsi yang diperlukan terkait dengan kelas itu, berapa banyak metode yang bisa kita lampirkan lebih lanjut?

Saya setuju bahwa memiliki lebih dari 15 metode, maka mungkin sedikit desain ulang mungkin diperlukan.
Tetapi bahkan dalam kasus itu, jika menghapus beberapa metode atau warisan bukanlah suatu pilihan, mana yang akan menjadi cara yang tepat?

Miliki metode sebanyak yang Anda butuhkan. Saya akan mencoba untuk menekan jumlah metode publik untuk aturan 5-8 jika memungkinkan. Sejujurnya, kebanyakan orang memiliki masalah yang berlawanan di mana mereka memiliki metode super gila yang perlu dipecahkan lebih banyak, bukan lebih sedikit. Tidak masalah berapa banyak metode pembantu pribadi yang Anda miliki. Bahkan, jika Anda tinggal di bawah 8 metode di Jawa Anda bisa mencapai batas dengan kelas yang hanya memiliki konstruktor, toString, dan pengambil / penyetel untuk 3 properti ... yang bukan kelas yang benar-benar kuat. Intinya adalah, jangan khawatir tentang berapa banyak metode kelas Anda. Khawatir memastikan kelas Anda tidak menghadapi masalah yang tidak terkait, dan bahwa Anda memiliki antarmuka publik yang masuk akal yang memiliki metode yang mudah dipahami.

Jawabannya sangat sederhana: Letakkan segala sesuatu di kelas yang menjadi tanggung jawabnya, tapi hati-hati saat menetapkan tanggung jawab.

Terkadang kelas besar adalah gabungan dari kelas yang lebih kecil dengan tanggung jawab yang berbeda.

Secara umum, saya mencoba untuk membagi tanggung jawab ke dalam kelas yang lebih kecil ketika kelas menjadi sulit digunakan atau dalam pemeliharaan. Saya jarang memiliki kelas yang lebih dari 500 baris. Kelas terbesar saya memiliki sekitar 1.5k locs.

Anda tidak bisa menyatakan aturan umum seperti "kelas harus memiliki antara metode n dan m".

Tidak ada alasan (dalam desain OO) untuk hanya memiliki begitu banyak metode. Juga tidak benar bahwa kelas dengan metode yang lebih sedikit dipisahkan lebih baik.

Lihatlah kelas java.lang.String, misalnya. Banyak metode, karena ada begitu banyak hal yang dapat dilakukan dengan sebuah string. Meskipun demikian tidak digabungkan dengan kuat.

Saya bertanya-tanya mengapa angka ajaib seperti 15 dapat memisahkan desain yang baik dan yang buruk. Tidak, itu tidak mudah.

Dalam PMD, perilaku default aturan TooManyMethods adalah untuk mengidentifikasi dan menandai kelas dengan 10 metode atau lebih sebagai potensi kesalahan. Ini hanya angka acak. Mudah diubah dalam konfigurasi. Terlepas dari apa nomor ini, itu hanya bendera bagi pengembang untuk melihat kelas dan melihat apakah ada masalah, bukan berarti ada masalah dengan itu.

Sesuatu yang sedikit lebih konkret mungkin adalah aturan 7 plus / minus 2 . Ini menyatakan bahwa pikiran manusia dapat memegang dan memahami antara 5 dan 9 "objek" dalam memori. Saat membaca kelas tertentu, objek kemungkinan besar adalah metode dan bidang yang membentuk kelas itu. Namun, kelas sering memiliki lebih dari 9 bidang dan metode, bahkan jika Anda tidak menghitung accesor, mutator dan setiap operasi standar (misalnya, toString(), hashCode(), dan equals()di Jawa).

Langkah-langkah yang paling relevan adalah fan-in dan fan-out dan diskusi tentang coupling dan kohesi . The prinsip tanggung jawab tunggal dan pemisahan keprihatinan harus diterapkan - kelas harus melakukan atau mewakili satu hal dan satu hal saja. Ini jauh lebih baik daripada mencoba menetapkan angka ke metode maksimum / minimum ketika menilai suatu desain atau implementasi.