Single Reponsibility Principle ( SRP )

SRP (Single Reponsibility Principle) term pertama dalam SOLID principles. Gagasan utama dari prinsip ini yaitu sebuah class seharusnya hanya memilki satu tugas dan hanya boleh memiliki satu alasan untuk dirubah. Mungkin kalimat yang cukup membingungkan, tapi akan coba dijelaskan pada tulisan ini. Tapi sebelum itu, inilah gambaran besar ide yang akan kita gunakan pada series ini. Kita akan menggunakan ide Vending Machine sederhana sebagai ide dasarnya.

Tulisan ini adalah bagian dari SOLID Principles Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Seperti yang terlihat pada flow pada di atas, ketika pengguna selesai memilih produk, maka Vending Machine akan mengupdate info stock dan mengirim notifikasi ke admin dashboard. Jika diubah ke dalam bentuk code, maka programmer kurang lebih akan membuat code seperti ini.

class OrderService {

    async execute(dto: RequestDTO) {}

    validatePayload(dto: RequestDTO) {
        // Memvalidasi setiap key dan value yang dikirim dari sisi client
    }

    async getProduct() {
        // Meng-query database langsung disini untuk mendapatkan info product
    }

    calculateNewAvailableStock() {
        // Mengurangi jumlah stock
    }

    async saveUpdateStock() {
        // Meng-query database untuk menyimpan perubahan di database
    }

    async sendNotifyAdmin() {
        // Mengirim notifikasi ke email atau sms
    }
}

Seperti yang terlihat pada code di atas, class tersebut memiliki banyak tugas di dalamnya, sehingga class tersebut tidak memiliki kejelasan tugas pokoknya. Query ke sql, notifikasi dan logic usecase order ada dalam satu class mengakibatkan class tersebut terlihat kompleks. Akan menjadi lebih kompleks jika feature semakin banyak akibat dari keharusan aplikasi untuk mengikuti perkembangan bisnis dari perusahaan tersebut. Semakin kompleks sistem, jika tidak di-manage dengan baik, maka akan menjadi lebih sulit untuk tracing issue ketik terjadi error.

Akibat yang sering terjadi adalah, programmer akan kurang percaya diri atau khawatir ketika code tersebut akan dideploy ke production. Lebih jauh lagi, karena terlalu kompleks, akhirnya programmer memutuskan untuk merubah keseluruhan class tersebut, yang akan membuat probabilitas error pada program semakin besar. Akan memperparah probabilitas error dengan tidak adanya unit test atau integration test.

Lalu bagaimana agar code tersebut agar mudah dimaintain/diurus? Yaitu dengan cara memisahkan logic menjadi class-class yang sesuai dengan tugasnya. Seperti code ini.

class OrderUsecase {
    async execute(dto: OrderRequestDTO): Promise<OrderResponseDTO> {}
    validate(dto: OrderReqeustDTO): boolean {}
    async getStock(id: number): Promise<ProductEntity> {}
    calculateStock(product: ProductEntity) {}
}

class OrderRepository {
    async getProductById(id: number): Promise<ProductEntity> {}
    async updateProduct(id: number, product: ProductEntity): Promise<ProductEntity> {}
}

class OrderNotification() {
    async sendAsWebsocket() {}
    async sendAsSMS() {}
}

Bisa kita lihat dari code di atas, setiap class sekarang memiliki tugasnya yang lebih spesifik. Misal class OrderUsecase hanya memiliki satu tugas untuk alur utama usecase order, untuk class OrderRepository digunakan khusus untuk yang berhubungan dengan database, dan untuk class OrderNotification tugasnya hanya yang berhubungan dengan notifikasi. Sebagaimana syarat SRP, class hanya boleh miliki satu tugas saja.

Lalu dimisalkan perlu perubahan pada logic khusus Order Usecase, berarti programmer hanya perlu merubah class OrderUsecase saja, tidak perlu merubah class lain. Jika ingin merubah yg berhubungan dengan database, berarti yang dirubah bukan class OrderUsecase melainkan OrderRepository. Sesuai dengan syarat SRP, class hanya boleh dirubah karena satu alasan saja.

Kesimpulan

Single Responsibiliy Princple akan memperjelas tugas dari setiap class. Semakin jelas tugas sebuah class, maka akan semamkin mempermudah programmer ketika akan melakukan tracing masalah.

Selanjutnya akan membahas tentang point ketiga dari SOLID, yaitu Open Closed Principle

reference:

• http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod