Single Responsibility Principle (SRP) dalam Paradigma Pemrograman Berorientasi Objek

informatika wajib coding - freepik
Serial Prinsip SOLID Dalam Paradigma Pemrograman Berorientasi Objek
Oleh Andhik Budi Cahyono

SOLID adalah prinsip-prinsip yang dapat membantu para pengembang perangkat lunak dalam merancang dan membangun program yang berkualitas tinggi dan mudah untuk dipelihara. Pemeliharaan yang mudah dan kualitas perangkat lunak yang baik bisa membuat umur perangkat lunak jadi lebih lama dan tentu saja menguntungkan bagi pengembang maupun penggunanya. Selain itu, dengan prinsip SOLID, perubahan kebutuhan di masa yang akan datang jadi lebih mudah untuk diakomodasi. SOLID sendiri merupakan akronim dari lima prinsip dasar dalam pemrograman berorientasi objek, yaitu: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, dan Dependency Inversion

Definisi dan Tujuan SRP

Prinsip Single Responsibility (SRP) merupakan prinsip pertama dari SOLID. Prinsip ini menyatakan bahwa: 

“Sebuah kelas seharusnya hanya memiliki satu tanggung jawab, tugas, atau fokus pada satu tujuan tertentu dan hanya memiliki satu alasan untuk berubah” 

SRP sangat penting dalam pengembangan perangkat lunak karena dapat membantu mengurangi kompleksitas, meningkatkan keterbacaan, dan mempermudah perawatan kode program. Dengan menerapkan prinsip SRP, setiap bagian dari program memiliki satu tujuan yang jelas dan terpisah dari tugas lain, sehingga perubahan atau penambahan fitur pada satu bagian tidak akan memengaruhi bagian lain.

Implementasi dan Contoh SRP

SRP tidak berarti dalam satu kelas hanya boleh memiliki satu buah method (fungsi/prosedur) saja. Sebuah kelas bisa saja memiliki lebih dari satu fungsi, tetapi fungsi-fungsi yang dimilikinya masih relevan dan terkait dengan tugas utama dari kelas tersebut. Sebagai contoh, sebuah kelas untuk mengelola basis data tidak seharusnya juga bertanggung jawab untuk mengirim email atau menghasilkan laporan karena tugas-tugas tersebut memiliki tanggung jawab yang berbeda. Fungsi-fungsi yang berkaitan dengan pengiriman email dan generate laporan bisa dibuatkan pada kelas tersendiri. 

Berikut contoh kode program yang belum menerapkan SRP: 

public class Payment {

    private double amount;

    private String paymentMethod;

    public Payment(double amount, String paymentMethod) {

        this.amount = amount;

        this.paymentMethod = paymentMethod;

    }

    public double getAmount() {

        return amount;

    }

    public void setAmount(double amount) {

        this.amount = amount;

    }

    public String getPaymentMethod() {

        return paymentMethod;

    }

    public void setPaymentMethod(String paymentMethod) {

        this.paymentMethod = paymentMethod;

    }

 

// kode ini belum optimal dan bisa dioptimalkan dengan prinsip SOLID yang lain

    public void processPayment() {

        if (paymentMethod.equals(“credit card”)) {

            // Process credit card payment

        } else if (paymentMethod.equals(“debit card”)) {

            // Process debit card payment

        } else if (paymentMethod.equals(“paypal”)) {

            // Process PayPal payment

        } else {

            // Invalid payment method

        }

    }

 // fungsi yang memiliki tugas berbeda atau tidak relevan

    public void sendPaymentConfirmationEmail() {

        // Send payment confirmation email

    }

}

Sekilas mungkin terlihat tidak ada masalah pada kelas Payment tersebut baik secara semantik maupun sintaksis. Namun, kelas tersebut melanggar prinsip SRP karena memiliki dua tugas yaitu: memproses pembayaran dan mengirimkan email konfirmasi pembayaran. Fungsi sendPaymentConfirmationEmail() sebaiknya dipisahkan dari kelas Payment dan diletakkan pada kelas baru, misalnya kelas PaymentConfirmationSender. Kode program di atas bisa diperbaiki menjadi: 

Payment.java

public class Payment {

    private double amount;

    private String paymentMethod;

    public Payment(double amount, String paymentMethod) {

        this.amount = amount;

        this.paymentMethod = paymentMethod;

    }

    public double getAmount() {

        return amount;

    }

    public void setAmount(double amount) {

        this.amount = amount;

    }

    public String getPaymentMethod() {

        return paymentMethod;

    }

    public void setPaymentMethod(String paymentMethod) {

        this.paymentMethod = paymentMethod;

    }

 

// kode ini belum optimal dan bisa dioptimalkan dengan prinsip   SOLID yang lain

    public void processPayment() {

        if (paymentMethod.equals(“credit card”)) {

            // Process credit card payment

        } else if (paymentMethod.equals(“debit card”)) {

            // Process debit card payment

        } else if (paymentMethod.equals(“paypal”)) {

            // Process PayPal payment

        } else {

            // Invalid payment method

        }

    }

}

PaymentConfirmationSender.java

public class PaymentConfirmationSender {

    public void sendPaymentConfirmationEmail() {

        // Send payment confirmation via email

    }

    public void sendPaymentConfirmationWhatsapp() {

        // Send payment confirmation via whatsapp    

    }

}

Kedua kelas bisa dihubungkan ketika proses checkout dilakukan, misalnya seperti contoh kode berikut: 

public void checkout() {

    Payment payment = new Payment(100000, “paypal”);

    payment.processPayment();

    PaymentConfirmationSender emailSender = new PaymentConfirmationSender();

    emailSender.sendPaymentConfirmationEmail();

}

Dalam fungsi checkout() di atas, setelah proses pembayaran selesai diproses, objek PaymentConfirmationSender digunakan untuk mengirim email konfirmasi pembayaran. Dengan cara ini, tanggung jawab pengiriman email telah dipisahkan dari kelas Payment dan kelas Payment hanya bertanggung jawab untuk menyimpan informasi pembayaran dan memproses pembayaran. Fungsi checkout() bisa ditaruh pada kelas tersendiri, kelas Checkout misalnya, yang memiliki tugas menyelesaikan rangkaian proses checkout seperti menerima input dari pengguna, melakukan validasi, memproses pembayaran, dan mengirim email konfirmasi pembayaran.

Demikian penjelasan dan pembahasan mengenai salah satu prinsip SOLID yaitu Single Responsibility Principle (SRP). Pada kesempatan berikutnya, kita akan membahas prinsip kedua yaitu Open-Closed Principle

*masukan untuk tulisan ini bisa disampaikan langsung ke email: [email protected]

[/FA]