Prinsip tanggung jawab tunggal: Kelas, hanya satu alasan yang menyebabkan perubahannya.
Mengapa prinsip tanggung jawab tunggal diperlukan?
Jika suatu kelas memiliki banyak alasan untuk memodifikasinya, maka memodifikasi fungsi dapat menyebabkan bug ke fungsi lain, jadi yang terbaik adalah memiliki hanya satu tanggung jawab untuk kelas. Tetapi masih sulit untuk dicapai dalam aplikasi praktis, jadi kami hanya dapat mencoba yang terbaik untuk mematuhi prinsip ini.
Kadang -kadang, pengembang akan memiliki beberapa masalah saat merancang antarmuka, seperti properti pengguna dan perilaku pengguna dinyatakan dalam antarmuka. Ini menyebabkan objek bisnis dan logika bisnis disatukan, yang menyebabkan antarmuka memiliki dua tanggung jawab. Tanggung jawab antarmuka tidak jelas, dan sesuai dengan definisi SRP, itu melanggar prinsip tanggung jawab tunggal antarmuka.
Inilah contohnya:
paket com.loulijun.chapter1; antarmuka publik Itutu {// tinggi batal setshengao (tinggi ganda); getshengao ganda (); // berat batal settizhong (berat ganda); gettizhong ganda (); // Eat Boolean Chifan (Boolean Hungry); // di Internet Boolean Shangwang (Boolean Silly); }Contoh di atas memiliki masalah ini. Tinggi dan berat badan milik objek bisnis, dan metode yang sesuai terutama bertanggung jawab atas atribut pengguna. Makan dan berselancar di internet adalah logika bisnis yang sesuai, yang terutama bertanggung jawab atas perilaku pengguna. Tetapi ini akan memberi orang perasaan bahwa mereka tidak tahu apa yang dilakukan antarmuka ini, tanggung jawabnya tidak jelas, dan berbagai masalah juga akan disebabkan selama pemeliharaan selanjutnya.
Solusi: Prinsip tanggung jawab tunggal, pecahkan antarmuka ini menjadi dua antarmuka dengan tanggung jawab yang berbeda.
Itutubo.java: Bertanggung jawab atas atribut tutu (tutu, jika itu nama pribadi)
paket com.loulijun.chapter1; /*** Bo: Objek Bisnis, Objek Bisnis* Bertanggung jawab atas atribut pengguna* Administrator @Author**/Antarmuka publik Itutubo {// tinggi batal setshengao (tinggi ganda); getshengao ganda (); // berat batal settizhong (berat ganda); gettizhong ganda (); }Itutubl.java: bertanggung jawab untuk menempatkan
paket com.loulijun.chapter1; /*** BL: Logika Bisnis, Logika Bisnis* Bertanggung jawab atas Perilaku Pengguna* Administrator @Author**/Antarmuka Publik ITutubl {// Makan Chifan Boolean Makanan (Boolean Hungry); // hiburan Boolean Shangwang (Boolean Silly); }Ini mewujudkan tanggung jawab tunggal antarmuka. Kemudian saat menerapkan antarmuka, ada dua kelas yang berbeda
Tutubo.java
paket com.loulijun.chapter1; Tutubo kelas publik mengimplementasikan itutubo {private double height; bobot ganda pribadi; @Override public double getshengao () {return height; } @Override public double gettizhong () {return weight; } @Override public void setshengao (tinggi ganda) {this.height = tinggi; } @Override public void settizhong (bobot ganda) {this.weight = bobot; }}Tutubl.java
paket com.loulijun.chapter1; Kelas publik Tutubl mengimplementasikan ItUtubl {@Override public boolean chifan (boolean hungry) {if (hungry) {System.out.println ("Pergi untuk memiliki hot pot ..."); Kembali Benar; } return false; } @Override Public Boolean Shangwang (Boolean Silly) {if (konyol) {System.out.println ("Sangat membosankan, pergi ke internet ..."); Kembali Benar; } return false; }}Ini membuatnya jelas. Ketika Anda perlu memodifikasi atribut pengguna, Anda hanya perlu memodifikasi antarmuka ITUTUBO, yang hanya akan mempengaruhi kelas Tutubo dan tidak akan mempengaruhi kelas lain.
Meringkaskan:
1. Situasi sebenarnya adalah bahwa berkali -kali kita tidak dapat melihat "penyebab perubahan" sebelumnya, sehingga kita hanya dapat membangun antarmuka kita berdasarkan pengalaman dan mencoba memastikan bahwa satu antarmuka hanya memiliki satu tanggung jawab. Apa yang kita bicarakan di sini adalah antarmuka. Kelas dapat mewarisi dan mengimplementasikan banyak antarmuka, membuatnya lebih sulit untuk mencapai tanggung jawab tunggal.
2. Ketika kelas yang saya tulis sebelumnya memiliki beberapa alasan untuk perubahan, yang terbaik adalah refactor.
Namun, ada masalah dengan prinsip menggunakan tanggung jawab tunggal. Tidak ada standar divisi yang jelas untuk "tanggung jawab". Jika tanggung jawab dibagi terlalu rinci, itu akan menyebabkan peningkatan tajam dalam jumlah antarmuka dan kelas implementasi, yang akan meningkatkan kompleksitas dan mengurangi pemeliharaan kode. Karena itu, saat menggunakan tanggung jawab ini, kita juga harus menganalisis situasi spesifik. Sarannya adalah bahwa antarmuka harus mengadopsi prinsip tanggung jawab tunggal, dan mewujudkan prinsip tanggung jawab tunggal sebanyak mungkin dalam desain kelas. Yang terbaik adalah menyebabkan perubahan dalam kelas jika satu alasan disebabkan.