'
Selamat datang di posting pertama seri “Design Patterns Exposed”. Dalam seri ini kita akan mengungkap setiap Pola Desain dari awal.
Mengetahui bahasa pemrograman dan konstruksinya tidak akan membuat Anda menjadi programmer atau developer yang lebih baik. Dibutuhkan pengetahuan tentang Pola Desain untuk membuat perangkat lunak yang akan berfungsi saat ini dan juga di masa depan.
Banyak pengembang telah menemukan masalah desain yang Anda hadapi saat ini atau yang akan Anda hadapi di masa depan. Mereka telah menetapkan cara standar untuk menangani masalah itu. Jadi dengan menggunakan Pola Desain Anda mendapatkan keuntungan menggunakan teknik yang telah terbukti.
Setiap Pola Desain adalah untuk memecahkan jenis situasi tertentu, mungkin ada situasi di mana lebih dari satu Pola Desain dapat digunakan.
apa append lakukan di java
Sebagian besar programmer hanya mencoba memecahkan masalah yang mereka hadapi tanpa mempedulikan pola desain, kode yang berlebihan atau bahkan hubungan yang erat. Tetapi programmer yang baik memulai dengan cara yang berbeda. Mereka memikirkan tentang persyaratan hari ini, persyaratan masa depan, pemeliharaan kode, dan kegunaan kembali kode.
Pemrogram yang baik tidak akan terburu-buru memulai pengkodean setelah mereka mendapatkan persyaratannya. Mereka duduk dan memikirkan masalah apakah desain mereka akan berhasil. Jika ya, apakah itu akan berhasil setelah 6 bulan, saat persyaratan akan berubah.
Pemrogram yang baik mengambil pena dan kertas mereka dan mulai merancang kelas dan hubungan antar kelas. Mereka mencoba untuk mendapatkan kopling longgar dan kohesi tinggi dalam desain mereka, sementara melakukan semua ini mereka memiliki Prinsip Berorientasi Objek dalam pikiran mereka. Mereka tidak langsung masuk ke dalam kode tingkat rendah. Untuk merancang perangkat lunak yang fleksibel dan dapat digunakan kembali, Anda harus mengikuti pendekatan ini jika tidak, Anda akan selalu menemukan diri Anda memodifikasi kode yang telah Anda tulis sebelumnya.
Hanya ada satu hal yang konstan dalam industri perangkat lunak dan itu adalah Perubahan. Persyaratannya pasti akan terus berubah. Jadi, bagaimana kami merancang perangkat lunak yang kode Anda dapat dengan mudah beradaptasi dengan kebutuhan masa depan? Untuk itu Anda harus memulainya lebih awal, dan mendesainnya sedemikian rupa sehingga persyaratan di masa mendatang tidak merusak kode Anda sebelumnya.
Bagaimana saya bisa melakukan itu?
Nah, itu bisa dilakukan dengan mengikuti Design Principles dan Design Patterns berdasarkan prinsip-prinsip tersebut.
Sekarang, mari selami pengkodean dan memulai perjalanan untuk menjadi programmer yang lebih baik. Dalam posting ini, kami akan mengungkap salah satu pola terpenting - Pola Strategi .
Ketika saya mengatakan yang paling penting itu mencerminkan masalah umum yang diselesaikan dengan Pola Strategi.
Apa itu Pola Strategi?
Berikut adalah definisi langsung dari buku 'Gang of Four': “Pola Strategi digunakan untuk membuat keluarga algoritme yang dapat dipertukarkan dari mana proses yang diperlukan dipilih pada saat run-time'.
Dalam kasus Andatidak bisa mengerti, jangan khawatir, kami akan menjelaskannya dilebih sederhanacarauntukmumemahami.
Pertama-tama mari kita pahami masalahnya dan kemudian kita akan melihat bagaimana Pola Strategi dapat menyelesaikannya.
Pada diagram UML di atas, kita memiliki kelas abstrak Hewan dan dua kelas beton, Anjing dan Burung, yang diturunkan dari kelas super Hewan.
Jadi mari kita tentukan kelas abstrak Hewan dan dua kelas konkret, Anjing dan Burung.
Apa pendapat Anda tentang desain di atas? Ada satu kesalahan besar dalam desain kami.
Semua hewan tidak bisa terbang, seperti dalam kasus di atas seekor anjing tidak bisa terbang. Tapi tetap saja memiliki perilaku 'terbang'.
Kami membuat kesalahan dengan menulis metode fly () abstrak di dalam kelas Animal. Desain ini akan memaksa setiap sub-kelas Anjing, Burung, Penguin, Buaya, Angsa dll untuk menerapkan metode fly ().
Kita seharusnya memahami bahwa terbang adalah kemampuan yang tidak dimiliki semua hewan. Dengan memberikan metode fly () pada kelas abstrak hewan kita telah menetapkan kemampuan terbang pada semua sub kelas yang tidak tepat untuk semua sub kelas hewan.
Anda mungkin berpikir apa masalah dalam mengimplementasikan metode fly di sub-kelas. Meskipun Anda dapat menerapkan metode fly () di sub-kelas Hewan bukan terbang untuk hanya mencetak 'Saya tidak bisa terbang'. Namun masalahnya, Anda tetap memberikan perilaku lalat kepada hewan yang tidak bisa terbang. Ini tidak benar.
Bagaimana rasanya memanggil dog.fly () atau crocodile.fly ().
Jadi, sekarang kita telah memahami bahwa desain kita salah dan kita harus menghapus metode fly () dari sub-kelas Animal.
Apa cara lain untuk mendesain kelas kita sehingga desain kita tidak memaksa semua sub-kelas Hewan untuk berperilaku terbang.
Salah satu solusi yang langsung terlintas dalam pikiran adalah kita dapat membuat antarmuka terbang dengan metode terbang dan hanya hewan yang dapat terbang yang akan menerapkan antarmuka terbang tersebut. Dengan cara ini kami tidak akan menerapkan semua sub-kelas Hewan untuk menentukan perilaku lalat. Jadi mari kita kodekan pendekatan desain ini.
Sekarang, kelas Hewan kita akan terlihat seperti kode di bawah ini setelah menghapus metode lalat dari kelas Hewan.
Sekarang mari kita tentukan antarmuka Terbang
Sekarang, kelas Anjing akan diubahsebagaikode di bawah ini dan tidak perlu memiliki perilaku terbang.
Mari kita lihat beberapa sub-kelas Hewan kami yang akan memiliki perilaku terbang.
Kami telah menyelesaikan masalah kami sebelumnya, tetapi kami mendapat masalah baru yaitu 'Duplikasi Kode'.
Katakanlah, kita akan memiliki 100 sub-kelas Hewan terbang yang berbeda. Kita harus menduplikasi kode untuk perilaku terbang karena antarmuka terbang tidak dapat menyediakan implementasi apapun untuk perilaku terbang, dan kemudian jika kita ingin mengubah implementasi metode fly () di sub-kelas manapun kita harus membuka kelas itu dan mengubah kodenya, mana yang buruk. Kami kekurangan sesuatu yang besar dan, yaitu, kami tidak dapat mengubah perilaku terbang sebuah kelas pada saat berjalan.
Tapi jangan khawatir, Pola Strategi siap membantu Anda keluar dari masalah ini.
Jadi mari kita perbarui kode kita untuk menggunakan Pola Strategi.
Antarmuka terbang akan tetap sama seperti aslinya. Sekarang, daripada setiap sub-kelas terbang yang mengimplementasikan antarmuka terbang itu sendiri, kita akan mendefinisikan kelas-kelas beton terpisah yang akan mengimplementasikan perilaku terbang yang berbeda. Mari kita lihat bagaimana melakukannya.
Jadi, bagaimana semuanya bekerja, mari kita lihat TestClass
Dengan menggunakan Pola Strategi, kami sekarang dapat mengubah perilaku terbang hewan mana pun pada saat berjalan dan itu tanpa memaksakan sub-kelas apa pun untuk menentukan perilaku terbang itu sendiri.
Kapan menggunakan Pola Strategi?
Saat Anda ingin dapat mengubah perilaku pada waktu proses secara dinamis.
Untuk memastikan Anda memahami dengan jelas Pola Strategi, mari kita ambil contoh lain.
Di kelas Karyawan di atas, kami menetapkan gaji karyawan tergantung pada penunjukannya. Jika seorang karyawan adalah 'Magang', kami menambahkan 10% bonus dalam gaji pokok untuk menghitung gaji sebenarnya.
Jika seorang karyawan adalah 'Pengembang Web', kami menambahkan 20% bonus dalam gaji pokok untuk menghitung gaji sebenarnya dan proses serupa mengikuti untuk jenis karyawan lainnya. Meskipun algoritme kami untuk menghitung gaji sebenarnya sangat sederhana untuk membuatnya lebih mudah dipahami, tetapi sering kali, algoritme kami menyertakan banyak perbandingan dan penghitungan.
Jadi, apa yang salah dengan kode kelas karyawan?
Nah, kode untuk menghitung pembayaran (getPay ()) bersifat statis. Misalkan saya ingin mengubah bonus untuk 'Magang' dari 10% menjadi 14%. Saya harus membuka kode kelas Karyawan dan mengubahnya.
Dan masalah lainnya adalah saya tidak dapat mengubah algoritme pembayaran karyawan pada saat menjalankan. Jadi, bagaimana caranya? Pola Strategi khusus digunakan untuk menangani masalah semacam ini.
Mari kita refactor kodenya untuk menggunakan Pola Strategi.
Saya akan mendefinisikan beberapa algoritma untuk menghitung pembayaran. Kemudian saya akan dapat menggunakan salah satu algoritme ini untuk menghitung pembayaran pada saat menjalankan.
Sekarang, mari kita lihat bagaimana kelas Karyawan akan berubah.
catatan: Saya telah menghapus logika perhitungan gaji dari kelas Karyawan dan membuat metode set Algoritma () di mana saya akan mengatur Algoritme Pembayaran yang ingin saya gunakan untuk perhitungan pembayaran.
Ini akan memberi saya fleksibilitas untuk menghitung pembayaran dengan menentukan Algoritme Pembayaran apa pun secara dinamis pada saat berjalan. Juga, perhatikan bahwa nanti jika saya harus mengubah logika penghitungan gaji, saya dapat membuat Algoritme Pembayaran baru dan menggunakannya untuk menghitung pembayaran. Saya tidak perlu mengubah kode sebelumnya, bukankah itu bagus?
Jadi mari kita lihat ini berhasil.
Saya harap Anda memahami Pola Strategi dengan baik. Cara terbaik untuk mempelajari sesuatu adalah dengan berlatih.
Jika Anda memiliki pertanyaan terkait Pola Strategi atau Pola lainnya, tinggalkan pertanyaan Anda di bawah.
Nantikan posting berikutnya, di mana kita akan mengungkap salah satu Pola Desain paling populer, Pola Pabrik.
Sampai saat itu Anda dapat mengunduh permainan kode dengannya dan memastikan Anda mengokohkan Pola Strategi di kepala Anda.
Ada pertanyaan untuk kami? Sebutkan mereka di bagian komentar dan kami akan menghubungi Anda kembali.
Posting terkait: