Cukup sering saya bertemu pengembang yang belum pernah mendengar tentang prinsip SOLID (kami . β Terjemahan) atau pemrograman berorientasi objek (OOP), atau pernah mendengarnya, tetapi tidak menggunakannya dalam praktik. Artikel ini menjelaskan manfaat prinsip OOP yang membantu pengembang dalam pekerjaan sehari-hari. Beberapa di antaranya terkenal, yang lainnya tidak begitu terkenal, jadi artikel ini akan berguna baik bagi programmer pemula maupun berpengalaman.
Kami mengingatkan: untuk semua pembaca Habr - diskon 10 rubel saat mendaftar di kursus Skillbox apa pun menggunakan kode promo Habr.
Skillbox merekomendasikan: Kursus online pendidikan .
KERING (Jangan Ulangi Sendiri)
Prinsip yang cukup sederhana, yang intinya jelas dari namanya: βJangan ulangi.β Bagi seorang programmer, ini berarti kebutuhan untuk menghindari duplikat kode, serta kemampuan untuk menggunakan abstraksi dalam pekerjaannya.
Jika ada dua bagian berulang dalam kode, keduanya harus digabungkan menjadi satu metode. Jika nilai hardcode digunakan lebih dari sekali, ada baiknya mengubahnya menjadi konstanta publik.
Hal ini diperlukan untuk menyederhanakan kode dan mempermudah pemeliharaan, yang merupakan tujuan utama OOP. Anda juga tidak boleh menggunakan gabungan secara berlebihan, karena kode yang sama tidak akan lolos verifikasi dengan OrderId dan SSN.
Mengenkapsulasi Perubahan
Produk perangkat lunak sebagian besar perusahaan terus berkembang. Artinya perlu dilakukan perubahan pada kode, perlu didukung. Anda dapat membuat hidup Anda lebih mudah dengan menggunakan enkapsulasi. Ini akan memungkinkan Anda menguji dan memelihara basis kode yang ada dengan lebih efisien. .
Jika Anda menulis di Java, maka .
Prinsip terbuka/tertutup
Prinsip ini dapat dengan mudah diingat dengan membaca pernyataan berikut: βEntitas perangkat lunak (kelas, modul, fungsi, dll.) harus terbuka untuk perluasan, tetapi tertutup untuk modifikasi.β Dalam praktiknya, ini berarti mereka dapat membiarkan perilakunya diubah tanpa mengubah kode sumbernya.
Prinsip ini penting ketika perubahan pada kode sumber memerlukan revisi kode, pengujian unit, dan prosedur lainnya. Kode yang mengikuti prinsip terbuka/tertutup tidak berubah ketika diperluas, sehingga masalah yang ada jauh lebih sedikit.
Berikut adalah contoh kode yang melanggar prinsip ini.
Jika Anda perlu mengubah sesuatu di dalamnya, itu akan memakan banyak waktu, karena semua bagian kode yang memiliki hubungan dengan fragmen yang diinginkan harus diubah.
Omong-omong, keterbukaan-ketertutupan adalah salah satu prinsip SOLID.
Prinsip Tanggung Jawab Tunggal (SRP)
Prinsip lain dari himpunan SOLID. Dinyatakan bahwa βhanya ada satu penyebab yang menyebabkan perubahan kelas.β Kelas hanya memecahkan satu masalah. Ini mungkin memiliki beberapa metode, tetapi masing-masing metode hanya digunakan untuk memecahkan masalah umum. Semua metode dan properti seharusnya hanya melayani hal ini.
Nilai dari prinsip ini adalah melonggarkan hubungan antara masing-masing komponen perangkat lunak dan kode. Jika Anda menambahkan lebih dari satu fungsi ke suatu kelas, hal ini akan memperkenalkan hubungan antara kedua fungsi tersebut. Jadi, jika Anda mengubah salah satunya, ada kemungkinan besar merusak yang kedua, yang terhubung dengan yang pertama. Dan ini berarti meningkatkan siklus pengujian untuk mengidentifikasi semua masalah terlebih dahulu.
Prinsip Inversi Ketergantungan (DIP)
Di atas adalah contoh kode di mana AppManager bergantung pada EventLogWriter, yang pada gilirannya digabungkan erat dengan AppManager. Jika Anda memerlukan cara lain untuk menampilkan notifikasi, baik itu push, SMS, atau email, Anda perlu mengubah kelas AppManager.
Masalah tersebut dapat diselesaikan dengan menggunakan DIP. Jadi, alih-alih AppManager, kami meminta EventLogWriter, yang akan dimasukkan menggunakan kerangka kerja tersebut.
DIP memudahkan penggantian modul individual dengan modul lain dengan mengubah modul ketergantungan. Hal ini memungkinkan untuk mengubah satu modul tanpa mempengaruhi modul lainnya.
Komposisi bukannya warisan
Ada dua cara utama untuk menggunakan kembali kode: pewarisan dan komposisi, keduanya memiliki kelebihan dan kekurangan masing-masing. Biasanya yang kedua lebih disukai karena lebih fleksibel.
Komposisi memberi Anda kemampuan untuk mengubah perilaku kelas saat runtime dengan mengatur propertinya. Saat mengimplementasikan antarmuka, polimorfisme digunakan, yang memberikan implementasi lebih fleksibel.
Even Effective Java oleh Joshua Bloch menyarankan untuk memilih komposisi daripada warisan.
Prinsip Pergantian Barbara Liskov (LSP)
Prinsip lain dari toolkit SOLID. Dinyatakan bahwa subtipe harus dapat menggantikan supertipe. Artinya, metode dan fungsi yang bekerja dengan superkelas harus dapat bekerja dengan subkelasnya tanpa masalah.
LSP dikaitkan dengan prinsip tanggung jawab tunggal dan prinsip tanggung jawab bersama. Jika suatu kelas menyediakan lebih banyak fungsionalitas daripada subkelas, maka subkelas tersebut tidak akan mendukung beberapa fungsi tersebut, sehingga melanggar prinsip ini.
Berikut adalah potongan kode yang bertentangan dengan LSP.
Metode luas(Persegi Panjang r) menghitung luas Persegi Panjang. Program akan crash setelah mengeksekusi Square karena Square bukan Rectangle di sini. Menurut prinsip LSP, fungsi yang menggunakan referensi ke kelas dasar harus dapat menggunakan objek kelas turunan tanpa instruksi tambahan.
Prinsip ini, yang merupakan definisi spesifik dari suatu subtipe, diusulkan oleh Barbara Liskov dalam keynote konferensi tahun 1987 yang berjudul βAbstraksi dan Hierarki Dataβ, sesuai dengan namanya.
Prinsip Pemisahan Antarmuka (ISP)
Prinsip SOLID lainnya. Menurutnya, antarmuka yang tidak digunakan sebaiknya tidak diterapkan. Mengikuti prinsip ini membantu sistem tetap fleksibel dan cocok untuk pemfaktoran ulang ketika ada perubahan pada logika operasi.
Paling sering, situasi ini terjadi ketika antarmuka berisi beberapa fungsi sekaligus, dan klien hanya memerlukan salah satunya.
Karena menulis antarmuka adalah tugas yang sulit, mengubahnya setelah pekerjaan selesai tanpa merusak apa pun akan menjadi sebuah tantangan.
Keuntungan prinsip ISP di Java adalah semua metode harus diimplementasikan terlebih dahulu, baru kemudian dapat digunakan oleh kelas. Oleh karena itu, prinsipnya memungkinkan untuk mengurangi jumlah metode.
Pemrograman untuk antarmuka, bukan implementasi
Semuanya di sini jelas dari judulnya. Penerapan prinsip ini mengarah pada pembuatan kode fleksibel yang dapat bekerja dengan implementasi antarmuka baru apa pun.
Anda harus menggunakan tipe antarmuka untuk variabel, tipe pengembalian, atau tipe argumen metode. Contohnya adalah menggunakan SuperClass daripada SubClass.
I.e:
Daftar nomor= getNumbers();
Tapi tidak:
Nomor ArrayList = getNumbers();
Berikut adalah implementasi praktis dari apa yang dibahas di atas.
Prinsip delegasi
Contoh umum adalah metode sama dengan() dan kode hash() di Java. Ketika perlu untuk membandingkan dua objek, tindakan ini didelegasikan ke kelas yang sesuai, bukan ke kelas klien.
Keuntungan dari prinsip ini adalah tidak ada duplikasi kode dan relatif mudah untuk mengubah perilaku. Hal ini juga berlaku untuk delegasi acara.
Semua prinsip ini memungkinkan Anda menulis kode yang lebih fleksibel, indah, dan andal dengan kohesi tinggi dan kopling rendah. Tentu saja teori itu bagus, tetapi agar pengembang benar-benar menggunakan pengetahuan yang diperoleh, diperlukan praktik. Setelah Anda menguasai prinsip-prinsip OOP, langkah Anda selanjutnya mungkin mempelajari pola desain untuk memecahkan masalah umum pengembangan perangkat lunak.
Skillbox merekomendasikan:
- Tentu saja praktis .
- Kursus online terapan .
- Kursus praktik dua tahun .
Sumber: www.habr.com