Tanggung jawab tunggal mungkin bukan sesuatu yang dapat dipenuhi fungsi tunggal.
class Location {
public int getX() {
return x;
}
public int getY() {
return y;
}
}
Kelas ini dapat melanggar prinsip tanggung jawab tunggal. Bukan karena memiliki dua fungsi, tetapi jika kode untuk getX()dan getY()harus memenuhi pemangku kepentingan yang berbeda yang mungkin menuntut perubahan. Jika Wakil Presiden Tn. X mengirim sekitar memo bahwa semua angka akan dinyatakan sebagai angka titik mengambang dan Direktur Akuntansi Ny. Y menegaskan bahwa semua angka yang ditinjau oleh departemennya akan tetap bilangan bulat terlepas dari apa yang dipikirkan dengan baik oleh Tn maka kelas ini sebaiknya memiliki satu ide tentang siapa yang bertanggung jawab karena semuanya akan membingungkan.
Jika SRP telah diikuti, akan menjadi jelas jika kelas Lokasi berkontribusi untuk hal-hal yang diungkapkan oleh X dan kelompoknya. Perjelas apa yang menjadi tanggung jawab kelas dan Anda tahu arahan apa yang mempengaruhi kelas ini. Jika keduanya berdampak pada kelas ini maka itu dirancang dengan buruk untuk meminimalkan dampak perubahan. "Kelas seharusnya hanya memiliki satu alasan untuk berubah" tidak berarti seluruh kelas hanya dapat melakukan satu hal kecil. Itu berarti saya seharusnya tidak dapat melihat kelas dan mengatakan bahwa Tuan X dan Ny. Y memiliki ketertarikan pada kelas ini.
Selain hal-hal seperti itu. Tidak, banyak metode baik-baik saja. Berikan saja nama yang menjelaskan metode apa yang termasuk dalam kelas dan apa yang tidak.
SRP Paman Bob lebih tentang Hukum Conway daripada Hukum Curly . Paman Bob menganjurkan menerapkan Hukum Curly (melakukan satu hal) untuk fungsi bukan kelas. SRP memperingatkan terhadap pencampuran alasan untuk berubah bersama. Hukum Conway mengatakan sistem akan mengikuti bagaimana arus informasi organisasi. Itu mengarah pada mengikuti SRP karena Anda tidak peduli dengan apa yang tidak pernah Anda dengar.
"Modul harus bertanggung jawab pada satu, dan hanya satu, aktor"
Robert C Martin - Arsitektur Bersih
Orang-orang terus menginginkan SRP menjadi alasan untuk membatasi ruang lingkup. Ada lebih banyak alasan untuk membatasi ruang lingkup daripada SRP. Saya selanjutnya membatasi ruang lingkup dengan menegaskan bahwa kelas adalah abstraksi yang dapat mengambil nama yang memastikan bahwa melihat ke dalam tidak akan mengejutkan Anda .
Anda bisa menerapkan Hukum Curly ke kelas. Anda di luar apa yang Paman Bob bicarakan tetapi Anda bisa melakukannya. Di mana Anda salah adalah ketika Anda mulai berpikir itu berarti satu fungsi. Itu seperti berpikir keluarga seharusnya hanya memiliki satu anak. Memiliki lebih dari satu anak tidak menghentikannya menjadi keluarga.
Jika Anda menerapkan hukum Curly ke kelas, semua yang ada di kelas harus tentang satu ide pemersatu. Gagasan itu bisa luas. Idenya mungkin kegigihan. Jika beberapa fungsi utilitas logging ada di sana, maka mereka jelas tidak pada tempatnya. Tidak masalah jika Mr X adalah satu-satunya yang peduli dengan kode ini.
Prinsip klasik untuk diterapkan di sini disebut Pemisahan Kekhawatiran . Jika Anda memisahkan semua kekhawatiran Anda, dapat dikatakan bahwa yang tersisa di satu tempat adalah satu perhatian. Itulah yang kami sebut ide ini sebelum film 1991 City Slickers memperkenalkan kami pada karakter Curly.
Ini baik Hanya saja apa yang Paman Bob sebut sebagai tanggung jawab bukan masalah. Tanggung jawab kepadanya bukanlah sesuatu yang Anda fokuskan. Itu adalah sesuatu yang bisa memaksa Anda untuk berubah. Anda dapat fokus pada satu masalah dan masih membuat kode yang bertanggung jawab kepada berbagai kelompok orang dengan agenda berbeda.
Mungkin Anda tidak peduli tentang itu. Baik. Berpikir bahwa memegang untuk "melakukan satu hal" akan menyelesaikan semua kesengsaraan desain Anda menunjukkan kurangnya imajinasi tentang apa yang "satu hal" dapat akhirnya menjadi. Alasan lain untuk membatasi ruang lingkup adalah organisasi. Anda dapat membuat banyak "satu hal" di dalam yang lain "satu hal" sampai Anda memiliki laci sampah penuh dengan segalanya. Saya sudah membicarakan hal itu sebelumnya
Tentu saja alasan klasik OOP untuk membatasi ruang lingkup adalah karena kelas memiliki bidang pribadi di dalamnya dan alih-alih menggunakan getter untuk membagikan data tersebut, kami menempatkan setiap metode yang membutuhkan data tersebut di kelas tempat mereka dapat menggunakan data secara pribadi. Banyak yang menemukan ini terlalu ketat untuk digunakan sebagai batasan ruang lingkup karena tidak setiap metode yang dimiliki bersama menggunakan bidang yang sama persis. Saya ingin memastikan bahwa ide apa pun yang menyatukan data menjadi ide yang sama yang menyatukan metode.
Cara fungsional untuk melihat ini adalah a.f(x)dan a.g(x)hanya f a (x) dan g a (x). Bukan dua fungsi tetapi rangkaian pasangan fungsi yang berbeda-beda. The abahkan tidak harus memiliki data di dalamnya. Itu bisa saja bagaimana Anda tahu mana fdan gimplementasi yang akan Anda gunakan. Fungsi yang berubah bersama menjadi satu. Itu polimorfisme lama yang bagus.
SRP hanyalah salah satu dari banyak alasan untuk membatasi ruang lingkup. Itu bagus. Tapi bukan satu-satunya.