S.O.L.I.D Principle - Single Responsibility Principle (SRP)

'S' dari Solid merupakan Single Responsibility Principle.

Ketika dulu saya belum mengenal prinsip ini, class yang saya buat sering kali memiliki banyak fungsi.

Sebagai contoh saya memiliki sebuah class 'Activity' yang memiliki fungsi mulai dari pemanggilan API, mapping data, penyimpanan ke database, dsb. Disamping class yang complex, fungsi / method yang saya buat dulu juga sangat complex sebagai contoh: di dalam fungsi onCreate() dari 'Activity' saya melakukan pemanggilan API, mapping data, penyimpanan database semua disitu, sehingga fungsi dan class yang saya buat tersebut jadi sulit untuk dimaintenance, tidak bisa ditest, dan sulit untuk dimengerti oleh developer lain, saya sendiri baru baru ini membukanya dan berkata dalam hati "Ini Siapa yang menulis code seperti ini", padahal saya sendiri yang menulisnya.

💡 A class or module should have one, and only one, reason to be changed - Uncle Bob

Uncle Bob menyatakan bahwa sebuah class atau module sebaiknya memiliki hanya satu alasan untuk berubah yang berarti hanya memiliki satu tanggung jawab dalam sebuah class / module

Kenapa class yang saya miliki tidak boleh mempunyai banyak responsibility / alasan untuk mengubahnya ?

Seiring dengan berjalannya waktu, requirement yang dibutuhkan pada suatu project akan berganti mulai dari improvement, bugfix, fitur baru, dan lain sebagainya. Ketika anda mengubah class yang berhubungan dengan requirement untuk menyesuaikan dengan requirement, anda akan melakukan test ulang pada class teresebut, dan mengatasi side-effect karena perubahaan yang anda lakukan.

Jika class anda memiliki banyak responsibility maka class akan sering mengalami perubahaan karena memiliki banyak alasan untuk berubah, dan berakibat terjadinya conflict saat melakukan merge request.

Contoh

data class Customer(val name: String, val email: String) {
    fun save() {
        // save to database for example
    }
}

code diatas merupakan contoh code yang melanggar Single Responsibility Principle, karena memiliki lebih dari 1 alasan untuk mengubah kode tersebut, yakni:

1. Jika terjadi perubahan di dalam implementasi fungsi save
2. Jika terjadi perubahan entity pada customer

Mari kita pertimbangkan beberapa skenario yang mungkin saja bisa terjadi.

1. Product Owner ingin menambahkan attribute alamat di dalam entity customer maka kita akan menambahkan attribute address kedalam class customer
2. Product Owner ingin menghapus data customer, maka kita perlu menambahkan fungsi hapus pada class customer
3. Developer yang bertanggung jawab atas entity costumer menambahkan attribute address dan Developer yang bertanggung jawab atas proses manajemen data customer masing-masing melakukan perubahan, dan ketika merge request dilakukan akan terjadi conflict di dalam class Customer.

Implementasi Single Responsibility Principle

data class Customer(val name: String, val email: String)

Dengan begini class Customer memiliki satu reason to change yaitu: Perubahaan pada Entitas Customer

class CustomerRepository() {
    fun save(customer: Customer) {
       // save to database for example
    }
}

Dan class CustomerRepository memiliki satu reason to change yaitu: Perubahaan pada Manajemen Data Customer

Akhir Kata

Untuk membuat sebuah code yang dapat dimaintenance dengan baik, dapat dimengerti, dapat ditest, serta untuk menghindari conflict ketika merge request. Mengetahui Single Responsibility Principle ini sangat penting.

Prinsip ini tidak hanya digunakan pada Pemrograman Berbasis Object(OOP) saja, dan implementasinya tidak terpaku pada class saja melainkan setiap component software, mulai dari fungsi / method, class, module, dsb.

Apakah saya harus mengadopsi prinsip ini ?
Dalam kebanyakan kasus akan sangat berguna ketika anda Single Responsibility Principle, tapi ini bukan suatu aturan yang pasti. Anda juga harus bijak dalam merancang solusi, dan anda mungkin tidak selalu mendapatkan manfaat dari mengadopsi prinsip ini.