Menjadi pengembang SOLID

Dec 24 2022

Dengan mengikuti prinsip rekayasa perangkat lunak SOLID

Disebut solid adalah pujian. Kata itu membawa pengertian positif tentang keandalan dan kehormatan.

Disebut solid adalah pujian. Kata itu membawa pengertian positif tentang keandalan dan kehormatan. Kita semua harus bertujuan untuk menjadi satu.

https://www.collinsdictionary.com/dictionary/english/solid (tangkapan layar)

Jika Anda seorang insinyur perangkat lunak atau ingin menjadi insinyur perangkat lunak, Anda beruntung karena ada seperangkat prinsip SOLID untuk memandu jalan Anda.

SOLID adalah akronim dalam profesi rekayasa perangkat lunak. Itu singkatan dari:

Prinsip tanggung jawab tunggal
O prinsip tertutup pena
Prinsip Pergantian L iskov
Prinsip segregasi antarmuka
Prinsip inversi ketergantungan

Mari kita lihat prinsip-prinsip ini lebih terinci.

Tanggung Jawab Tunggal

Setiap kelas harus memiliki satu tanggung jawab.

An EmailServiceseharusnya hanya memperhatikan pengiriman email, bukan dengan mengirim email dan memperbarui status pesanan.

Kelas Carharus tentang mobil saja, bukan jenis kendaraan bermotor lainnya. Jika kita perlu mendeskripsikan mobil listrik, maka subkelas seperti ElectricCaritu lebih tepat daripada kelebihan muatan Cardengan karakteristik mobil listrik dan bensin.

Prinsip buka-tutup

Modul harus terbuka untuk ekstensi tetapi tertutup untuk modifikasi

Itu EmailServicedapat diperpanjang dengan RecallableEmailServicemenambahkan fitur kemampuan mengingat ke email yang baru saja dikirim.

Layanan Email dan asosiasinya

Menambahkan fitur ElectricCarelektrik tanpa memodifikasi internal .Car

substitusi Liskov

Subclass harus dapat diganti untuk kelas dasarnya

Dalam konteks desain berorientasi objek, kelas atau metode yang menerima turunan dari kelas dasar harus dapat mengambil turunan dari subkelasnya.

An OrderServiceharus dapat menggunakan instance apa pun yang sesuai dengan antarmuka EmailServicetanpa memperhatikan bahwa kelas sebenarnya dari instance itu EmailServicesendiri atauRecallableEmailService

Seorang UrbanTripPlannerharus dapat menggunakan contoh apa pun Caruntuk menentukan rute tanpa mengetahui apakah itu mewakili mobil listrik atau bensin.

Segregasi antarmuka

Banyak antarmuka khusus klien lebih baik daripada satu antarmuka tujuan umum

An OrderServicetidak perlu recallEmail(...). Oleh karena itu hanya tergantung pada EmailServicepengiriman email, bukanRecallableEmailService

Demikian pula, an UrbanTripPlannertidak memerlukan recharge(...)metode dari EletricCar. Itu hanya bergantung pada antarmuka yang disediakan olehCar

Mobil dan asosiasinya

Inversi ketergantungan

Bergantung pada Abstraksi. Jangan bergantung pada beton.

Mekanisme dependensi prosedural dimulai dari atas, berkembang secara bertahap, dan bergantung pada detail implementasi yang konkret.

Dalam pemrograman berorientasi objek, ketergantungannya terbalik . Sebagian besar ketergantungan harus pada abstraksi. Dan di mana ada implementasi, hubungannya dengan abstraksi terbalik . Alih-alih bergantung secara langsung, implementasinya sekarang bergantung pada abstraksi.

Sumber: Prinsip Desain dan Pola Desain Paman Bob

OrderServiceTergantung pada antarmuka yang disediakan oleh dan EmailServicebukan implementasi IMAP atau POP-nya.

UrbanTripPlannerTergantung pada antarmuka yang disediakan oleh , Carbukan penerapan Tesla atau Toyota

Kesimpulan

Kami telah memeriksa asal akronim SOLID, serta melihat masing-masing secara rinci dengan masing-masing 2 kasus penggunaan desain berorientasi objek.

Anda mungkin telah mengikuti beberapa prinsip ini di masa lalu tanpa mengetahuinya karena itu adalah praktik yang baik. Enkapsulasi, menurut saya, mengikuti prinsip Buka-tutup .

Anda mungkin juga telah menerapkan beberapa di antaranya karena begitulah adanya. Secara sintaksis, sebuah ElectricCarobjek selalu dapat meneruskan Carparameter, dengan demikian mengikuti prinsip substitusi Liskov . Jika Anda telah menggunakan Injeksi Ketergantungan, Anda sudah mengikuti prinsip Pembalikan Ketergantungan .

Prinsip-prinsip lain membutuhkan sedikit pemikiran. Prinsip Tanggung Jawab Tunggal membutuhkan model OO yang baik untuk menjaga metode/kelas/modul tetap bersih dan ramping. Anda mungkin memerlukan penilaian yang baik untuk menentukan seberapa dalam segregasi harus mengikuti prinsip Interface Segregation .