Forem: Alfian Akmal Hanantio

S.O.L.I.D Principle - Liskov Substitution Principle (LSP)

Alfian Akmal Hanantio — Sun, 20 Jun 2021 16:11:04 +0000

Open Closed Principle yang sudah saya tulis di artikel sebelumnya merupakan salah satu kunci dari konsep Pemrograman Berbasis Objek (Object Oriented Programming) dimana memungkinkan kamu untuk menulis code yang robust, dapat dimaintenance, dan reusable software components. Namun hanya mengadopsi prinsip ini saja tidak cukup untuk memastikan bahwa kamu dapat mengubah salah satu bagian dari sistemmu tanpa merusak bagian-bagian yang lain. class dan interface yang kamu miliki juga perlu mengadopsi Liskov Substitution Principle (LSP) untuk menghindari side-effect.

Liskov Substitution Principle ini memperluas Open Closed Principle dengan memfokuskan pada behavior dari superclass dan turunannya.

Apa itu Liskov Substitution Principle (LSP)

💡 If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. ~ Barbara Liskov

Kemudian Robert C. Martin merumuskan kembali definisi dari Liskov Substitution Principle yang dikemukakan oleh Barbara Liskov

💡 Subtypes must be substitutable for their base types.

Prinsip ini dapat juga diartikan bahwa objek-objek dari superclass seharusnya dapat digantikan dengan objek-objek yang merupakan turunan dari superclass tanpa merusak aplikasi. Dimana mengharuskan objek-objek dari turunan superclass memiliki behavior yang sama dengan superclassnya.

Kenapa LSP ini Penting ?

Pelanggaran LSP akan membuat code anda bau. Kita mungkin telah mengeneralisasi sebuah konsep secara premature dan membuat superclass dimana tidak diperlukan. Kebutuhan dimasa mendatang untuk konsep tersebut mungkin tidak sesuai dengan hierarki class yang kita buat.

Jika code klien tidak dapat menggantikan referensi superclass dengan objek-obej subclass secara bebas, maka akan dipaksa untuk melakukan pemeriksaan instanceof dan menangani beberapa subclass secara kusus. Jika code seperti ini tersebar di seluruh code kita maka akan sulit untuk maintenancenya.

open class Product {
    protected val _discount: Double
    fun getDiscount(): Double {
        return _discount
    }
}

class SpecialProduct : Product() {
    fun applyExtraDiscount() {
        _discount = _discount * 0.2
    }
}

fun main(args: Array<String>) {
    val birds = listOf<Product>(Product(), SpecialProduct())
    birds.forEach { it ->
         if (it is SpecialProduct) it.applyExtraDiscount()
         println(it.getDiscount())
    }
}

Setiap kali kita menambahkan atau memodifikasi subclass, kita harus menyusuri code base kita dan merubahnya di beberapa tempat, ini akan sulit dilakukan dan rawan akan kesalahan.

Solusi LSP

Code diatas berarti objek Produk tidak dapat digantikan oleh objek SpecialProduct karena kita melakukan validasi bahwa jika produk merupakan SpecialProduk maka kita akan memanggil fungsi applyExtraDiscount().

agar SpecialProduct dapat digunakan untuk menggantikan superclassnya maka kita akan menggunakan prinsip “Tell, don’t ask!”, dimana akan membantu kita untuk mengeliminasi type casting / type checking.

class SpecialProduct : Product() {

    override fun getDiscount() {
        applyExtraDiscount()
        return _discount
    }
    fun applyExtraDiscount() {
        _discount = _discount * 0.2
    }
}

fun main(args: Array<String>) {
    val birds = listOf<Product>(Product(), SpecialProduct())
    birds.forEach { it ->
         println(it.getDiscount())
    }
}

dengan begini kita tidak memerlukan typecasting karena kita telah mengubah method dengan cara mengoverride dan memanggil fungsi applyExtraDiscount() di dalamnya dengan begitu tidak diperlukan lagi untuk melakukan pengecekan bahwa untuk SpecialProduct. Serta code yang kita miliki jadi lebih robust, testable, dan maintenable karena telah mengikuti LSP.

Akhir Kata

Liskov Substitution Principle memperluas Open Closed Principle dan membuat kita dapat menggantikan objek dari superclass dengan objek-objeck turunannya tanpa merusak program yang sudah ada. Serta membantu kita untuk membuat hierarki yang sesuai antar tipe, dimana akan menjamin program kita untuk berjalan dengan benar tanpa side-effect yang tidak diinginkan.

S.O.L.I.D Principle - Open Closed Principle (OCP)

Alfian Akmal Hanantio — Mon, 14 Jun 2021 16:36:40 +0000

Open Closed Principle ini dapat didefinisikan sebagai berikut:

💡 Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

yang berarti setiap entitas perangkat lunak (class, module, fungsi, dsb.) sebaiknya terbuka untuk dilakukan ekstensi, dan tertutup untuk modifikasi. Kita seharusnya dapat menambahkan behavior baru tanpa perlu merubah implementasinya.

Tujuan dari prinsip ini untuk menghindari kemungkinan terjadinya bug-bug baru ketika kita merubah implementasi code yang sudah uda.

Ilustrasi Open Closed Principle:
Image Source

Seperti gambar Illustrasi di atas, Terdapat 1 Mesin Blender, dan beberapa wadah untuk blender yang digunakan untuk kasus-kasus yang berbeda, dimana ada yang untuk memblender daging, memblender buah, memblender bumbu dapur. Jadi wadah tersebut memiliki fungsi yang berbeda-beda tanpa harus merubah fungsi utama dari mesin blender.

Contoh Kasus

Kita ambil contoh Blender di atas. Misal anda memiliki class Blender yang memiliki fungsi untuk memblender buah buahan



class Blender {
    fun blend() {
        println("Mulai memblender")
    }
}

lalu ada kebutuhan dari Produk yang membuat class Blender anda dapat daging, dan bumbu dapur / rempah-rempah.

Jika anda tidak mengikuti prinsip Open Closed Principle mungkin saja anda akan melakukan hal seperti ini:



class Blender {
    fun blend(tipe: String) {
        when (tipe) {
            "BUAH" -> blendFruit()
            "DAGING" -> blendMeat()
            "REMPAH" -> blendSpices()
        }
    }

    private fun blendFruit() {
        println("Mulai memblender Buah")
    }

    fun blendMeat() {
        println("Mulai memblender Daging")
    }

    fun blendSpices() {
        println("Mulai memblender rempah-rempah")
    }
}

Jika anda melakukan hal tersebut sangat memungkinkan terciptanya bug baru karena anda telah mengubah code yang sebelumnya telah berjalan normal.

Code Improvement

Sekarang kita akan coba melakukan improvement agar sesuai dengan prinsip OCP.



interface Processor {
    fun process()
}

kita siapkan antarmuka / abstraksi yang akan kita gunakan sebagai cetakan processor-processor yang akan kita buat nanti.

Lalu kita mulai buat masing-masing processor menggunakan cetakan yang sudah ada.



class FruitProcessor() : Processor {
    override fun process() {
        println("Mulai memblender Buah")
    }
}



class MeatProcessor() : Processor {
    override fun process() {
        println("Mulai memblender Daging")
    }
}



class SpicesProcessor() : Processor {
    override fun process() {
        println("Mulai memblender rempah-rempah")
    }
}

setelah kita buat masing-masing processor nya untuk memproses masing-masing bahan olahan.

kita menambahkan parameter di fungsi blend dengan object Processor yang akan kita gunakan untuk memproses bahan olahan.



class Blender {
    fun blend(processor: Processor) {
        processor.process()
    }
}

Lantas apa yang terjadi ketika produk ingin menambahkan kebutuhan untuk memblender batu es (ice cube) ?

Kita tinggal membuat class baru yang mengimplementasikan interface Processor



class IceCubeProcessor() : Processor {
    override fun process() {
        println("Mulai memblender batu es")
    }
}

sehingga kita tidak perlu mengubah class Blender yang sebelumnya sudah berjalan.

Manfaat

fungsionalitas dari class 'X' dapat dengan mudah diperluas dengan fungsionalitas yang baru dengan dikemas dalam kelas yang terpisah dari class 'X' tanpa perlu mengubah implementasi di class 'X' (tidak ada perubahan di class 'X')
code anda menjadi loosely coupled
class 'Y' yang di pakai di dalam class 'X' dapat dengan mudah dimock (dipalsukan), sehingga membuat class 'X' lebih mudah untuk di test.

Akhir Kata

Sekian dan terimakasih, Saya harap anda bisa menerapkan prinsip ini sehingga code yang anda tulis akan mencadi lebih bersih, mudah untuk test, lebih mudah untuk dikembangkan lagi, dan dapat menunjang produktivitas anda.

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

Alfian Akmal Hanantio — Sat, 12 Jun 2021 23:17:57 +0000

'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:

Jika terjadi perubahan di dalam implementasi fungsi save
Jika terjadi perubahan entity pada customer

Mari kita pertimbangkan beberapa skenario yang mungkin saja bisa terjadi.

Product Owner ingin menambahkan attribute alamat di dalam entity customer maka kita akan menambahkan attribute address kedalam class customer
Product Owner ingin menghapus data customer, maka kita perlu menambahkan fungsi hapus pada class customer
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.

S.O.L.I.D Principle - Pengenalan

Alfian Akmal Hanantio — Sat, 12 Jun 2021 12:49:55 +0000

Pada kesempatan kali ini saya akan mencoba membahas tentang SOLID Principle yang merupakan sebuah prinsip yang menurut saya wajib untuk diketahui oleh para Developer.

Apa itu SOLID Principle ?

SOLID principle adalah sebuah prinsip yang dikelankan oleh Robert J. Martin (a.k.a Uncle Bob) di dalam paper yang di terbitkannya pada tahun 2000 Design Principles and Design Patterns dengan tujuan untuk membuat code yang dapat dimengerti, dapat dibaca, dan dapat test oleh banyak developer secara kolaboratif. Dalam 20 tahun terakhir kelima prinsip ini merevolusi dunia pemrograman berbasis object (OOP), merubah cara kita dalam menulis code.

Dengan mengadopsi kelima prinsip ini akan membantu kita dalam menulis sebuah code yang bersih, lebih maintanable, dan adaptive terhadap perubahan sering dengan berkembangnya project.

SOLID sendiri merupakan kependekan dari dari:

S - Single-responsiblity Principle
O - Open-closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle

Mari kita lihat penjabarannya dari masing-masing prinsip yang dikemukakan oleh Uncle Bob ini, pada kali ini saya akan mencoba menjelaskannya masing-masing prinsip agar mudah dimengerti dan membaginya dalam beberapa artikel agar lebih nyaman untuk dibaca dan tidak memakan waktu terlalu banyak untuk membacanya