DEV Community: Arif Bugaresa

Single Responsibility Principle (SRP)

Arif Bugaresa — Tue, 22 Sep 2026 07:29:14 +0000

Single Responsibility Principle (SRP) merupakan prinsip SOLID yang menyatakan bahwa sebuah kelas harus hanya memiliki satu tanggung jawab yang spesifik. Jika sebuah kelas memiliki lebih dari satu tanggung jawab dapat memengaruhi tanggung jawab yang lainnya maka dapat meningkatkan risiko bug.

Analoginya untuk studi kasus mengelola sebuah resto akan ada banyak pekerjaan yang harus dilakukan seperti memasak makanan, melayani pengunjung yang datang dan membersihkan meja tamu. jika hanya ada satu petugas yang bertanggung jawab atas seluruh tugas, kemungkinan besar akan kewalahan dalam mengelola resto tersebut. jika tiba tiba ada masalah di dapur maka pengunjung akan menunggu lebih lama untuk mendapatkan pelayanan. disisi lain jika banyak pengunjung yang datang di waktu yang bersamaan maka petugas tersebut mungkin tidak sempat untuk membersihkan ruangan. itu lah mengapa di restoran yang baik, seharusnya memiliki beberapa petugas seperti koki yang fokus untuk memasak hidangan, pelayan yang hanya fokus melayani pengunjung yang datang dan cleaning service yang bertugas untuk membersihkan seluruh ruangan.

Dalam konteks SRP, setiap kelas harus fokus pada tanggung jawab yang spesifik. Jika ada masalah di sebagian kode, seharusnya tidak akan memengaruhi kode yang lain. dengan menerapkan SRP ini maka code akan lebih mudah dikelola dan dipelihara.

mari kita lihat contoh kode tanpa menerapkan single responsibility principle berikut.

type UserService struct {
}

func (us *UserService) CreateUser() {
    fmt.Println("create user")
}

func (us *UserService) SendEmail() {
    fmt.Println("send email")
}

Pada contoh diatas UserService melanggar konsep SRP karena memiliki 2 tanggung jawab yaitu membuat user dan mengirim email. jika ada perubahan pada cara mengirim email maka kita perlu mengubah UserService padahal seharusnya UserService hanya bertanggung jawab untuk mengelola user saja.

untuk menerapkan konsep SRP maka kita perlu memisahkan tanggung jawab mengelola user dan tanggung jawab mengirim email.

type UserService struct {
}

func (us *UserService) CreateUser() {
    fmt.Println("create user")
}

type EmailService struct {
}

func (us *EmailService) SendEmail() {
    fmt.Println("send email")
}

Sekarang, UserService hanya memiliki tanggung jawab untuk mengelola user dan EmailService memiliki tanggung jawab untuk pengiriman email.

Beberapa dampak positif dari penerapan SRP:

Ketika sebuah class/struct dirancang dengan tanggung jawab yang jelas, kita akan lebih mudah memahami fungsi dan tujuan dari class/struct tersebut.
Dengan memisahkan tanggung jawab pengiriman email ke dalam EmailService, perubahan pada cara atau logika pengiriman email tidak akan memengaruhi UserService.
Karena EmailService memiliki tugas yang lebih spesifik, class/struct tersebut dapat digunakan kembali di bagian lain yang membutuhkan fungsi pengiriman email.

Understanding SOLID Principles

Arif Bugaresa — Tue, 22 Sep 2026 07:06:31 +0000

SOLID Principles berawal dari upaya para pakar perangkat lunak untuk membuat kode yang lebih terstruktur, fleksibel, dan mudah dipelihara. Pada akhir 1980-an, kompleksitas software membuat kode semakin sulit dipahami, dikembangkan, dan rentan terhadap bug. Beberapa prinsip kemudian diperkenalkan oleh tokoh seperti Barbara Liskov dengan Liskov Substitution Principle (LSP) pada 1987 dan Bertrand Meyer dengan Open/Closed Principle (OCP) pada 1988. Prinsip-prinsip tersebut bertujuan membuat desain OOP lebih konsisten dan mudah beradaptasi terhadap perubahan.

Pada awal 2000-an, Robert C. Martin (Uncle Bob) menggabungkan lima prinsip desain yang sudah ada menjadi satu konsep yang dikenal sebagai SOLID: Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), dan Dependency Inversion Principle (DIP). Sejak saat itu, SOLID menjadi salah satu landasan penting dalam pengembangan software modern karena membantu developer membuat kode yang modular, scalable, maintainable, dan lebih mudah beradaptasi terhadap perubahan.

Artikel ini diharapkan dapat memberikan pemahaman penerapan SOLID di bahasa go dan sebagai reminder pribadi saat merasa bahwa kode yang saya tulis terasa tidak rapi dan sulit dipahami.

kenapa kita perlu setidaknya mengetahui SOLID principle ini? menulis kode biasanya hanya sekedar membuat kode yang berfungsi sesuai kebutuhan saja, tetapi seiring berjalannya waktu kadang kita akan menyadari bahwa kode yang berfungsi saja tidak cukup. kode yang tidak terstruktur dengan baik akan menjadi mimpi buruk saat harus diperbaiki atau di optimize.

Berikut beberapa alasan mengapa kadang solid principle ini perlu untuk di ikuti:

kode yang terstruktur dengan baik tidak hanya lebih mudah untuk dimengerti, tetapi juga memudahkan tim lain yang mungkin harus bekerja dengan kode yang orang lain tulis.
mendesain kode yang fleksibel dan mudah diperluas membuat perubahan dapat dilakukan tanpa mempengaruhi bagian kode yang lain
membagi kode ke dalam tanggung jawab yang terpisah memudahkan dalam memperbaiki bug dengan lebih cepat dan efisien.
kode yang modular dan bersih memudahkan dalam memahami bagian-bagian progam dengan mudah.
membantu dalam pembuatan code skala besar yang scalable seiring bertambahnya fitur fitur lain nya.

Single Reponsibility Principle (SRP)
Single Responsibility Principle merupakan prinsip yang menyatakan bahwa sebuah kelas harus hanya memiliki satu tanggung jawab yang spesifik

Open/Closed Principle (OCP)
Open Closed Principle merupakan prinsip yang menyatakan bahwa sebuah entitas perangkat lunak terbuka untuk ekstensi atau menambahkan fitur baru tanpa mengubah code yang sudah ada

Liskov Subtitution Principle (LSP)
Liskov Substitution Principle merupakan prinsip yang menyatakan bahwa kelas turunan harus dapat menggantikan kelas dasarnya tanpa mengubah sifatnya

Interface Segregation Principle (ISP)
Interface Segregation Principle merupakan prinsip yang menyatakan bahwa sebuah klien tidak seharusnya dipaksa untuk bergantung pada metode-metode yang tidak digunakannya atau interface yang terlalu besar harus dipisah menjadi beberapa interface yang lebih spesifik sesuai dengan kebutuhan

Dependency Inversion Principle (DIP)
Dependency Inversion Principle merupakan prinsip yang menyatakan bahwa modul tingkat tinggi tidak boleh bergantung pada modul tingkat rendah. Keduanya harus bergantung pada abstraksi

References:
https://emmanueladeyemi180.medium.com/a-structured-guide-to-the-solid-principles-of-object-oriented-programming-oop-903c311489d1

Test Post Part 1

Arif Bugaresa — Tue, 22 Sep 2026 07:01:49 +0000

test

Test Post

Arif Bugaresa — Tue, 22 Sep 2026 07:01:22 +0000

Linked Url

Arif Bugaresa

Sep 22

Test Post Part 1

1 min read