Flutter dengan SOLID Principle
SOLID adalah akronim untuk lima prinsip desain berorientasi objek (OOD) pertama oleh Robert C. Martin (juga dikenal sebagai Paman Bob).

Flutter dengan SOLID Principle



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

Apa Itu SOLID Principle 🤔

S.O.L.I.D principle adalah sebuah prinsip yang dikenalkan oleh Robert J. Martin (a.k.a Uncle Bob) di dalam paper yang di terbitkannya pada tahun 2000 Design Principles and Design Patterns. Dalam 20 tahun terakhir kelima prinsip ini merevolusi dunia pemrograman berbasis object (OOP), merubah cara kita dalam menulis code.


SOLID help to develop software with a high level of rigidity.

Kepanjangan dari SOLID principle :

  • S → Single Responsibility Principle
  • O → Open Closed Principle
  • L → Liskov Substitution Principle
  • I → Interface Segregation principle
  • D → Dependency Inversion Principle

Tujuan SOLID

Apa yang dapatkan ketika menggunakan SOLID principle dalam program?

  • Kode pemrograman mudah di pahami atau dibaca.
  • Tolerasi terhadap perubahan.
  • Koponen dasar dapat digunakan kembali dalam bentuk Software System lainnya.
  • Dapat di test oleh developer secara kolaboratif.

SOLID Principles


🔥 Warning

”Sebelumnya mempelajari SOLID principle kamu harus memahami Object Orientation Programming dan Software Design Priciple terlebih dahulu!”


Single Responsibility Principle (SRP)



“A module should be responsible to one, and only one, reason to be changed” (Robert J. Martin)


Single Responsibility Principle (SRP) adalah sebuah princip yang digunakan untuk mengatur tanggung jawab dari sebuah entitas yang berada di dalam sebuah projek dalam hal ini adalah sebuah Module atau Class untuk memenuhi kebutuhan User.

Tanggung Jawab berati sebuah class punya 2 fungsionalitas yang tak memiliki keterkaitan untuk melahkukan perubahan, jadi memisahkan sebuah fungsionalitas menjadi dua class berbeda.

Studi kasus


🚫 Contoh Salah

Dari contoh di atas  Article banyak tanggung jawab (responsibility). Ini berpotensi untuk mempengaruhi fungsionalitas dan tanggung jawab lain yang saling berkaitan di dalam  tersebut.


✅ CONTOH BENAR

Dari contoh di atas class Article dibagi menjadi 2 tanggung jawab (responsibility) dan didalam nya terdapat beberapa fungsionalitas. Keunggulan SRP ini adalah kode yang dibuat lebih mudah dikelola dan diindentifikasi.



Open Closed Principle (OCP)



Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” (Robert J. Martin)

Open Closed Principle (OCP) adalah mengatur setiap perangkat lunak (class, module, fungsi dsb) harus terbuka untuk ditambahkan tetapi tertutup untuk dimodifikasi.

Tujuan utama OCP ini adalah salah satunya menghindari terjadinya bug disaat mengimplementasikan code yang sudah ada.

Implemantasi OCP menggunakan penggunaan  dan  pada kelas, ini bertujuan agar dapat dengan mudah memperbaiki setelah pengembangan tanpa mengganggu  yang mewarisi dan mudah ketika membuat fungsionalitas baru.

Studi kasus


🚫 Wrong Example

Dari contoh di atas  Human terdapat fungsional character dimana didalamnya terdapat kondisi untuk mengambil walk, eat, drink. Jika anda melahkukan hal tersebut sangaat memungkinkan terciptanya bug baru ketika anda mengubah code yang sebelunya telah berjalan normal.


✅ Correct Example

Dari class di atas, Human adalah class abstract yang akan kita gunakan sebagai sifat yang akan kita buat.

Class WalkHuman, EatHuman dan DrinkHuman ini adalah tempat untuk memproses sifat dari manusia. Class WalkHuman, EatHuman and DrinkHuman are the place for the process of class humans.


Semisal kita buat sifat baru SleepHuman baru kita tinggal extends dari class Human.




Liskov Substitution Principle (LSP)



Subtypes must be substitutable for their base types. (Robert J. Martin)


Liskov Substitution Principle (LSP) adalah aturan untuk hikari pewarisan. Hal ini mengharuskan kita untuk mendesain class-class yang kita miliki, sehingga ketergantuangan atara Klien dapat didistribusikan tanpa Klien mengetahui tentang perubahan yang ada. Oleh karena itu SubClass setidaknya dapat berjalan dengan cara yang sama seperti SuperClass nya.


Studi kasus


🚫 Wrong Example

Pada class Bird kita menemukan fungsi swim() . Apakah itu merupakan sifat Bird? TENTU TIDAK.

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.


✅ CONTOH BENAR

Prinsip ini bertujuan untuk mengurangi jumlah ketergantungan sebuah class terhadap interface class yang tidak dibutuhkan. Bisanya class memiliki ketergantungan terhadap class lainnya.



Interface Segregation Principle (ISP)



“Clients should not be forced to depend upon interfaces that they do not use” (Robert J. Martin)

Interface Segregation principle (ISP) ini bertujuan untuk mengurangi jumlah ketergantungan sebuah class terhadap interface class yang tidak dibutuhkan. Bisanya class memiliki ketergantungan terhadap class lainnya.

Dalam pembuatan   lebih baik membuat banyak   dengan fungsi yang spesifik. Hal ini lebih baik daripada membuat satu   dengan fungsi yang tidak spesifik. Tujuan dari pemisahan  adalah agar tidak memaksa  menggunakan kode yang tidak diperlukan.

Studi kasus


🚫 Wrong Example

Pada kode diatas bahwa interface Vehicle terdapat fungsi run(), stop() dan charger(). Untuk Bicycle apakah memutuhkan charger? TENTU TIDAK, tetapi ketika kamu membuat kode seperti diatas kamu harus mengimplementasikan kode tersebut bukan.


✅ CONTOH BENAR

Pada kode diatas kita bagi class interface menjadi 2 yaitu VehicleInterface dan ElectricInterface, untuk VihicleInterface memiliki fungsi umum, tetapi untuk ElectricInterface hanya terdapat fungsi charger() saja.

Oky semisal kita butuh feature Tesla, tesla sendiri membuthkan pengisian daya menggunakan Listrik. Oleh karena itu kita harus implementasikan VehicleInterface dan ElectricInterface .


Semisal kita ingin membuat feature baru yaitu Bicycle maka kita cukup implementasikan VehicleInterface saya.

Kita sudah memisahkan interface menjadi bagian-bagian kecil, ini merupakan kegunaan dan tanggung jawab dari interface tersebut. Ini akan mempermudah kita dalam penambahan feature baru, juga untuk penulisan kode lebih mudah dipahami oleh developer.



Dependency Inversion Principle (DIP)



”High-level modules should not depend on low-level modules. Both should depend on abstractions”. (Robert J. Martin)

Dependency Inversion Principle (DIP) ini bergantung atar kelas interface, daripada referensi langsung ke kelas lainnya.

Ada aturan yang berlaku untuk DIP ini adalah :

  • High-level modules tidak boleh tergantung pada Low-level modules. Dan keduanya harus bergantung pada Abstractions.
  • Abstractions tidak diperbolehkan bergantung pada Details. Details harus bergantung pada Abstractions.

HIGH LEVEL → Kelas yang berurusan dengan kumpulan fungsionalitas.
LOW LEVEL → Kelas yang bergantung jawab pada oprasi yang lebih detail. Semisal menulis ke database.

Studi kasus


Pada class EngineInterface terdapat funsi run() ini berfungsi menampilkan nama engine dari beberapa engine.

Pada class Bike kita buat parameter constractor. Dimana ketika masing-masing class tersebuat mengimplementasikan interface Engine. Bike dan EngineInterface adalah High Level. Dan untuk EngineDiesel dan ElectriEngine adalah Low Level.


Untuk menjalanjan kode diatas maka cukup daftarkan Engine yang ingin dijalankan. Dependency Inversion ini membuat sistem menjadi fleksible. ketergantungan antara dependencies pada kode hanya mengacu pada abstractions bukan dari sebuah class.

Dependency Inversion untuk Flutter dapat kamu gunakan packages get_it.

Kesimpulan

S.O.L.I.D is helpful to make a system, but it’s just a principle, not a rule one must obey. S.O.L.I.D principle can be used in any programming language. memang sangat membantu dalam membuat sebuah sistem, namun ini hanya prinsip saja bukan aturan yang harus diikuti. 

Kentungan mengunakan SOLID principle ini adalah :

  • Kode pemrograman mudah di pahami atau dibaca.
  • Tolerasi terhadap perubahan.
  • Koponen dasar dapat digunakan kembali dalam bentuk Software System lainnya.
  • Dapat di test oleh developer secara kolaboratif.

Kamu bisa lih contoh project Flutter yang sudah saya buat.

Check this out on Github

If you have the desire to learn Flutter, please click the button below to contact us:

I WANT TO LEARN FLUTTER NOW

Panemu Contact


Flutter dengan SOLID Principle
Nanang Prasetya 2 November, 2022
Share post ini
Arsip
Masuk untuk meninggalkan komentar
Running Odoo Using Docker Compose
Include sharing custom/additional addons