Ada butir kebenaran dalam saran itu, tetapi IMHO itu tidak diungkapkan dengan baik, sehingga mudah untuk salah paham dan / atau untuk dibawa ke ekstrem bodoh. Bagaimanapun, ini harus menjadi aturan praktis, bukan hukum keras. Dan Anda harus selalu menyiratkan dalam aturan seperti itu klausa "dalam batas wajar" , atau "tapi jangan lupa untuk menggunakan akal sehat Anda" :-)
Butir kebenaran adalah bahwa dalam praktiknya, kelas dan metode selalu cenderung tumbuh secara alami, bukan menyusut . Perbaikan bug di sini, ekstensi fitur kecil di sana, menangani kasus khusus di sana ... dan voila, kelas Anda yang dulu rapi dan kecil mulai membengkak. Seiring waktu, kode Anda hampir pasti cenderung menjadi kekacauan spageti yang mengerikan - kecuali jika Anda secara aktif melawan kecenderungan ini melalui refactoring . Refactoring hampir selalu menghasilkan banyak kelas / metode yang lebih kecil dari yang besar. Tapi tentu saja, ada batas yang masuk akal untuk miniaturisasi. Inti dari refactoring bukan untuk memiliki kelas dan metode yang lebih kecil, tetapi untuk membuat kode Anda lebih bersih, lebih mudah dipahami dan dipelihara . Pada titik tertentu, membuat metode / kelas Anda lebih kecil mulai mengurangi keterbacaan, bukan meningkatkannya. Arahkan ke arah optimal itu. Ini adalah area target yang buram dan bergerak, jadi Anda tidak perlu memukulnya tepat. Tingkatkan sedikit kode setiap kali Anda melihat ada masalah dengannya .
"As small as possible, but no smaller."