Prinsip Tanggung Jawab Tunggal
("setiap kelas seharusnya hanya memiliki satu tanggung jawab tunggal; dengan kata lain, setiap kelas harus memiliki satu, dan hanya satu, alasan untuk berubah")
Saya tidak setuju. Saya pikir suatu metode seharusnya hanya memiliki satu alasan untuk berubah, dan semua metode dalam suatu kelas harus memiliki hubungan logis satu sama lain , tetapi kelas itu sendiri mungkin benar - benar melakukan beberapa hal (terkait).
Dalam pengalaman saya, prinsip ini terlalu sering diterapkan terlalu bersemangat, dan Anda berakhir dengan banyak kelas kecil satu metode. Kedua toko tangkas tempat saya bekerja telah melakukan ini.
Bayangkan jika pencipta .Net API memiliki mentalitas seperti ini: daripada List.Sort (), List.Reverse (), List.Find () dll., Kita akan memiliki kelas ListSorter, ListReverser, dan ListSearcher!
Daripada berdebat lagi melawan SRP (yang secara teori tidak mengerikan) , saya akan membagikan beberapa pengalaman anekdot saya yang bertele-tele:
Di satu tempat saya bekerja, saya menulis sebuah pemecah aliran maks yang sangat sederhana yang terdiri dari lima kelas: satu simpul, satu grafik, satu pembuat grafik, satu pembuat grafik, dan satu kelas untuk menggunakan pembuat grafik / pemecah untuk menyelesaikan suatu masalah dunia nyata. Tidak ada yang sangat kompleks atau panjang (solver adalah yang terpanjang di ~ 150 baris). Namun, diputuskan bahwa kelas-kelas tersebut memiliki "tanggung jawab" terlalu banyak, sehingga rekan kerja saya mulai memperbaiki kode itu. Ketika mereka selesai, 5 kelas saya telah diperluas menjadi 25 kelas, yang total baris-kode-nya lebih dari tiga kali lipat dari aslinya. Alur kode tidak lagi jelas, juga bukan tujuan dari unit-tes baru; Saya sekarang kesulitan mencari tahu apa yang kode saya lakukan.
Di tempat yang sama, hampir setiap kelas hanya memiliki satu metode (satu-satunya "tanggung jawab"). Mengikuti alur dalam program hampir tidak mungkin, dan sebagian besar unit-test terdiri dari pengujian bahwa kelas ini memanggil kode dari kelas lain , yang tujuannya sama-sama merupakan misteri bagi saya. Ada ratusan kelas di mana seharusnya (IMO) hanya puluhan. Setiap kelas hanya melakukan satu "hal" , tetapi bahkan dengan konvensi penamaan seperti "AdminUserCreationAttemptorFactory" , sulit untuk mengatakan hubungan antara kelas.
Di tempat lain (yang juga memiliki mentalitas kelas-seharusnya-hanya-memiliki-satu-metode ), kami mencoba mengoptimalkan metode yang menghabiskan 95% waktu selama operasi tertentu. Setelah (agak bodoh) mengoptimalkannya sedikit, saya mengalihkan perhatian saya mengapa itu disebut bajillion kali. Itu disebut dalam loop di kelas ... yang metodenya disebut dalam loop di kelas lain .. yang juga disebut dalam loop ..
Semua mengatakan, ada lima tingkat loop yang tersebar di 13 kelas (serius). Apa yang sebenarnya dilakukan oleh satu kelas tidak mungkin ditentukan hanya dengan melihatnya - Anda harus membuat sketsa grafik mental tentang metode apa yang disebutnya, dan metode apa yang disebut metode itu, dan seterusnya. Jika semuanya disatukan dalam satu metode, panjangnya hanya sekitar 70 baris dengan metode-masalah kita bersarang dalam lima tingkat loop yang jelas.
Permintaan saya untuk mengubah 13 kelas menjadi satu kelas ditolak.