3.1 Lajang
Singleton adalah pola desain generik yang menjamin bahwa aplikasi single-threaded akan memiliki satu instance dari beberapa kelas, dan menyediakan titik akses global untuk instance ini.
Sangat sering, pemrogram pemula suka mengumpulkan metode utilitas ke dalam beberapa kelas statis - kelas yang hanya berisi metode statis. Pendekatan ini memiliki sejumlah kelemahan - misalnya, Anda tidak dapat meneruskan referensi ke objek dari kelas seperti itu, metode seperti itu sulit untuk diuji, dan sejenisnya.
Sebagai alternatif, solusi kelas singleton diusulkan: kelas yang hanya dapat memiliki satu objek. Saat mencoba membuat objek ini, objek ini hanya dibuat jika objek tersebut belum ada, jika tidak, referensi ke instance yang sudah ada akan dikembalikan.
Adalah penting bahwa dimungkinkan untuk menggunakan turunan dari kelas, karena dalam banyak kasus tersedia fungsionalitas yang lebih luas. Misalnya, kelas ini dapat mengimplementasikan beberapa antarmuka dan objeknya dapat diteruskan ke metode lain sebagai implementasi antarmuka. Apa yang tidak bisa dilakukan dengan sekumpulan metode statis.
Kelebihan:
- Metode terikat ke objek, bukan kelas statis - Anda bisa meneruskan objek dengan referensi.
- Metode objek jauh lebih mudah untuk diuji dan ditiru.
- Objek hanya dibuat saat dibutuhkan: inisialisasi objek malas.
- Mempercepat peluncuran awal program jika banyak lajang yang tidak diperlukan untuk diluncurkan.
- Sendiri dapat diubah lebih lanjut menjadi strategi-template atau beberapa objek semacam itu.
Minus:
- Menjadi lebih sulit untuk mengontrol balapan dan penundaan antar-thread.
- Sulit untuk menulis "penyendiri" multi-utas "dari kepala": akses ke singleton lama, idealnya, tidak boleh membuka mutex. Solusi terbukti lebih baik.
- Konflik antara dua utas karena satu utas yang belum selesai akan mengakibatkan penundaan.
- Jika objek dibuat dalam waktu lama, penundaan dapat mengganggu pengguna atau mengganggu waktu nyata. Dalam hal ini, lebih baik mentransfer pembuatannya ke tahap inisialisasi program.
- Fitur khusus diperlukan untuk pengujian unit - misalnya, untuk menempatkan perpustakaan dalam mode "non-kesepian" dan sepenuhnya mengisolasi pengujian satu sama lain.
- Diperlukan taktik khusus untuk menguji program yang sudah selesai, karena bahkan konsep "peluncuran yang paling sederhana" pun menghilang, karena kemampuan peluncuran bergantung pada konfigurasi.
3.2 Pabrik [Metode]
Metode pabrik adalah pola desain umum yang menyediakan subkelas (pewaris kelas) dengan antarmuka untuk membuat instance dari kelas tertentu. Pada saat pembuatan, keturunan dapat menentukan kelas mana yang akan dibuat.
Dengan kata lain, templat ini mendelegasikan pembuatan objek ke keturunan kelas induk. Ini memungkinkan Anda untuk menggunakan bukan kelas konkret dalam kode program, tetapi untuk memanipulasi objek abstrak pada level yang lebih tinggi.
Pola ini mendefinisikan antarmuka untuk membuat objek, tetapi menyerahkannya kepada subkelas untuk memutuskan kelas mana yang menjadi dasar objek. Metode pabrik memungkinkan kelas untuk mendelegasikan pembuatan subclass. Digunakan saat:
- kelas tidak mengetahui sebelumnya objek mana dari subkelas mana yang perlu dibuatnya.
- sebuah kelas dirancang sedemikian rupa sehingga objek yang diciptakannya ditentukan oleh subkelas.
- kelas mendelegasikan tanggung jawabnya ke salah satu dari beberapa subkelas pembantu, dan direncanakan untuk menentukan kelas mana yang mengambil alih tanggung jawab ini.
3.3 Pabrik Abstrak
Pabrik abstrak adalah pola desain generik yang menyediakan antarmuka untuk membuat keluarga objek terkait atau saling bergantung tanpa menentukan kelas konkretnya.
Pola tersebut diimplementasikan dengan membuat kelas abstrak Pabrik, yang merupakan antarmuka untuk membuat komponen sistem (misalnya, untuk antarmuka jendela, dapat membuat jendela dan tombol). Kemudian kelas ditulis yang mengimplementasikan antarmuka ini.
Ini digunakan dalam kasus di mana program harus independen dari proses dan jenis objek baru yang dibuat. Ketika diperlukan untuk membuat keluarga atau kelompok objek terkait, mengecualikan kemungkinan penggunaan objek secara bersamaan dari set yang berbeda dalam konteks yang sama.
Kekuatan:
- mengisolasi kelas tertentu;
- menyederhanakan penggantian keluarga produk;
- menjamin kompatibilitas produk.
Katakanlah program Anda bekerja dengan sistem file. Kemudian untuk bekerja di Linux Anda memerlukan objek LinuxFile, LinuxDirectory, LinuxFileSystem. Dan untuk bekerja di Windwos, Anda memerlukan kelas WindowsFile, WindowsDirectory, WindowsFileSystem.
Kelas Path, yang dibuat melalui Path.of(), adalah kasus seperti itu. Path sebenarnya bukan kelas, tetapi antarmuka, dan memiliki implementasi WindowsPath dan LinuxPath. Dan jenis objek apa yang akan dibuat disembunyikan dari kode Anda dan akan ditentukan saat runtime.
3.4 Prototipe
Prototipe adalah pola desain generatif.
Pola ini mendefinisikan jenis objek yang dibuat menggunakan instance prototipe dan membuat objek baru dengan menyalin prototipe ini. Ini memungkinkan Anda untuk menjauh dari implementasi dan mengikuti prinsip "pemrograman melalui antarmuka".
Kelas antarmuka/abstrak di bagian atas hierarki ditetapkan sebagai tipe yang dikembalikan, dan kelas turunan dapat menggantikan pewaris yang mengimplementasikan tipe ini di sana. Sederhananya, ini adalah pola pembuatan objek dengan mengkloning objek lain alih-alih membuatnya melalui konstruktor.
Pola tersebut digunakan untuk:
- menghindari upaya tambahan untuk membuat objek dengan cara standar (artinya menggunakan konstruktor, karena dalam hal ini konstruktor dari seluruh hierarki leluhur objek juga akan dipanggil), saat ini sangat mahal untuk aplikasi.
- hindari mewarisi pembuat objek dalam aplikasi klien, seperti yang dilakukan pola pabrik abstrak.
Gunakan pola desain ini ketika program Anda tidak peduli bagaimana ia membuat, menyusun, dan menyajikan produk:
- kelas yang dibuat ditentukan pada saat dijalankan, misalnya, menggunakan pemuatan dinamis;
- Anda ingin menghindari membangun hierarki kelas atau pabrik yang sejajar dengan hierarki kelas produk;
- instance kelas dapat berada di salah satu dari beberapa status yang berbeda. Mungkin lebih mudah untuk mengatur jumlah prototipe yang sesuai dan mengkloningnya, daripada membuat instance kelas secara manual dalam keadaan yang sesuai setiap saat.