Saya tidak merasa berguna akhir-akhir ini untuk berdebat tentang apa yang dilakukan dan tidak merupakan tanggung jawab tunggal atau satu alasan untuk berubah. Saya akan mengusulkan Prinsip Duka Minimum sebagai gantinya:
Prinsip Duka Minimum: kode harus berupaya meminimalkan kemungkinannya untuk membutuhkan perubahan atau memaksimalkan kemudahan untuk diubah.
Bagaimana dengan itu? Seharusnya tidak mengambil ilmuwan roket untuk mencari tahu mengapa ini dapat membantu mengurangi biaya perawatan dan mudah-mudahan itu tidak menjadi titik perdebatan tanpa akhir, tetapi seperti dengan SOLID pada umumnya, itu bukan sesuatu untuk diterapkan secara membabi buta di mana-mana. Itu adalah sesuatu yang perlu dipertimbangkan sambil menyeimbangkan pertukaran.
Adapun kemungkinan membutuhkan perubahan, itu turun dengan:
- Pengujian yang baik (peningkatan keandalan).
- Melibatkan hanya kode minimum yang diperlukan untuk melakukan sesuatu yang spesifik (ini dapat termasuk mengurangi kopling aferen).
- Hanya membuat kode badass sesuai fungsinya (lihat Prinsip Membuat Badass).
Adapun kesulitan membuat perubahan, itu naik dengan kopling eferen. Pengujian memperkenalkan kopling eferen tetapi meningkatkan keandalan. Dilakukan dengan baik, umumnya lebih baik daripada merugikan dan benar-benar dapat diterima dan dipromosikan oleh Prinsip Duka Minimum.
Make Badass Principle: kelas yang digunakan di banyak tempat harus mengagumkan. Mereka harus dapat diandalkan, efisien jika itu terkait dengan kualitas mereka, dll.
Dan Prinsip Buat Badass terikat dengan Prinsip Duka Minimum, karena hal-hal badass akan menemukan kemungkinan lebih rendah untuk membutuhkan perubahan daripada hal-hal yang menyedot apa yang mereka lakukan.
Saya akan mulai dengan menunjuk pada paradoks yang disebutkan di atas, dan kemudian menunjukkan bahwa SRP sangat tergantung pada tingkat granularitas yang ingin Anda pertimbangkan dan bahwa jika Anda mengambilnya cukup jauh, setiap kelas yang mengandung lebih dari satu properti atau satu metode melanggar saya t.
Dari sudut pandang SRP, sebuah kelas yang nyaris tidak melakukan apa pun tentu hanya memiliki satu (kadang-kadang nol) alasan untuk berubah:
class Float
{
public:
explicit Float(float val);
float get() const;
void set(float new_val);
};
Itu praktis tidak memiliki alasan untuk berubah! Lebih baik dari SRP. Ini ZRP!
Kecuali saya sarankan itu adalah pelanggaran terang-terangan terhadap Prinsip Make Badass. Ini juga sama sekali tidak berharga. Sesuatu yang tidak begitu banyak berharap tidak bisa menjadi badass. Ini memiliki terlalu sedikit informasi (TLI). Dan tentu saja ketika Anda memiliki sesuatu yang TLI, ia tidak dapat melakukan sesuatu yang benar-benar bermakna, bahkan dengan informasi yang dirangkumnya, sehingga ia harus membocorkannya ke dunia luar dengan harapan bahwa orang lain benar-benar akan melakukan sesuatu yang bermakna dan sombong. Dan kebocoran itu oke untuk sesuatu yang hanya dimaksudkan untuk mengumpulkan data dan tidak lebih, tetapi ambang itu adalah perbedaan seperti yang saya lihat antara "data" dan "objek".
Tentu saja sesuatu yang merupakan TMI juga buruk. Kami mungkin menempatkan seluruh perangkat lunak kami dalam satu kelas. Bahkan dapat memiliki satu runmetode. Dan seseorang bahkan mungkin berpendapat bahwa sekarang ada satu alasan yang sangat luas untuk berubah: "Kelas ini hanya perlu diubah jika perangkat lunak perlu ditingkatkan." Saya bodoh, tapi tentu saja kita bisa membayangkan semua masalah pemeliharaan dengan itu.
Jadi ada tindakan keseimbangan untuk granularity atau kekasaran objek yang Anda desain. Saya sering menilai dengan seberapa banyak informasi yang Anda miliki bocor ke dunia luar, dan seberapa banyak fungsionalitas bermakna yang dapat dilakukan. Saya sering mendapati Prinsip Make Badass bermanfaat di sana untuk menemukan keseimbangan sambil menggabungkannya dengan Prinsip Duka Minimum.