Karena pertanyaan Anda mencakup banyak alasan, dengan banyak asumsi, saya akan memilih subjek pertanyaan Anda:
Mengapa kita membutuhkan begitu banyak kelas dalam pola desain
Kita tidak. Tidak ada aturan yang berlaku umum yang mengatakan bahwa harus ada banyak kelas dalam pola desain.
Ada dua panduan utama untuk memutuskan di mana menempatkan kode, dan cara memotong tugas Anda menjadi unit kode yang berbeda:
- Kohesi: setiap unit kode (baik itu paket, file, kelas atau metode) harus dimiliki bersama . Yaitu, metode spesifik apa pun harus memiliki satu tugas, dan melakukannya dengan baik. Setiap kelas harus bertanggung jawab atas satu topik yang lebih besar (apa pun itu). Kami ingin kohesi yang tinggi.
- Coupling: setiap dua unit kode harus bergantung sesedikit mungkin pada satu sama lain - seharusnya tidak ada dependensi melingkar. Kami ingin kopling rendah.
Mengapa keduanya harus penting?
- Kohesi: metode yang melakukan banyak hal (misalnya, skrip CGI kuno yang melakukan GUI, logika, akses DB, dll. Semuanya dalam satu kode yang panjang berantakan) menjadi sulit digunakan. Pada saat penulisan ini, sangat menggoda untuk memasukkan pemikiran Anda ke dalam metode yang panjang. Ini berfungsi, mudah disajikan dan semacamnya, dan Anda dapat melakukannya. Masalah muncul kemudian: setelah beberapa bulan, Anda mungkin lupa apa yang Anda lakukan. Baris kode di bagian atas mungkin berjarak beberapa layar dari garis di bagian bawah; mudah untuk melupakan semua detail. Setiap perubahan di mana pun dalam metode ini dapat merusak sejumlah perilaku dari hal yang kompleks. Akan sangat sulit untuk refactor atau menggunakan kembali bagian dari metode ini. Dan seterusnya.
- Coupling: kapan saja Anda mengubah unit kode, Anda berpotensi menghancurkan semua unit lain yang bergantung padanya. Dalam bahasa ketat seperti Java, Anda mungkin mendapatkan petunjuk selama waktu kompilasi (yaitu, tentang parameter, pengecualian yang dinyatakan, dan sebagainya). Tetapi banyak perubahan tidak memicu seperti itu (yaitu perubahan perilaku), dan bahasa lain yang lebih dinamis, tidak memiliki kemungkinan seperti itu. Semakin tinggi kopling, semakin sulit untuk mengubah apa pun, dan Anda mungkin berhenti, di mana penulisan ulang yang lengkap diperlukan untuk mencapai beberapa tujuan.
Kedua aspek ini adalah "driver" dasar untuk setiap pilihan "di mana harus meletakkan apa" dalam bahasa pemrograman apa pun, dan paradigma apa pun (tidak hanya OO). Tidak semua orang secara eksplisit menyadarinya, dan butuh waktu, seringkali bertahun-tahun, untuk mendapatkan perasaan yang benar-benar tertanam dan otomatis tentang bagaimana perangkat lunak ini memengaruhi.
Jelas, kedua konsep itu tidak memberi tahu Anda apa yang sebenarnya harus dilakukan . Beberapa orang keliru dalam hal terlalu banyak, yang lain terlalu sedikit. Beberapa bahasa (memandang Anda di sini, Jawa) cenderung memihak banyak kelas karena sifatnya yang sangat statis dan pedantik dari bahasa itu sendiri (ini bukan pernyataan nilai, tetapi itu adalah apa adanya). Ini menjadi sangat nyata ketika Anda membandingkannya dengan bahasa yang lebih dinamis dan lebih ekspresif, misalnya Ruby.
Aspek lain adalah bahwa beberapa orang berlangganan pendekatan tangkas dari hanya menulis kode yang diperlukan saat ini , dan untuk melakukan refactor berat nanti, bila perlu. Dalam gaya pengembangan ini, Anda tidak akan membuat interface
ketika Anda hanya memiliki satu kelas pelaksana. Anda cukup mengimplementasikan kelas konkret. Jika, nanti, Anda membutuhkan kelas dua, Anda akan refactor.
Beberapa orang tidak bekerja seperti itu. Mereka membuat antarmuka (atau, lebih umum, kelas dasar abstrak) untuk apa pun yang pernah dapat digunakan secara lebih umum; ini menyebabkan ledakan kelas dengan cepat.
Sekali lagi, ada argumen untuk dan melawan, dan tidak masalah yang saya, atau Anda, sukai. Dalam hidup Anda sebagai pengembang perangkat lunak, Anda akan menghadapi semua hal yang ekstrem, mulai dari metode spaghetti yang panjang, hingga desain kelas yang tercerahkan, cukup besar, hingga skema kelas yang sangat meledak-ledak yang terlalu banyak direkayasa. Ketika Anda semakin berpengalaman, Anda akan tumbuh lebih banyak menjadi peran "arsitektur", dan dapat mulai memengaruhi ini ke arah yang Anda inginkan. Anda akan menemukan tengah emas untuk diri sendiri, dan Anda masih akan menemukan bahwa banyak orang akan tidak setuju dengan Anda, apa pun yang Anda lakukan.
Oleh karena itu, menjaga pikiran terbuka adalah hal yang paling penting, di sini, dan itu akan menjadi saran utama saya untuk Anda, melihat bahwa Anda tampaknya sangat kesakitan tentang masalah ini, menilai dari sisa pertanyaan Anda ...