Sedikit tentang pola desain generatif

Tema pola desain cukup populer. Banyak video direkam dan artikel ditulis. Gabungkan semua bahan ini dengan “anti-pola.” Kompleksitas tidak disengaja. Akibatnya, contoh-contohnya musykil, deskripsinya membingungkan, cara mendaftarnya tidak jelas. Dan tugas utama pola desain - penyederhanaan (kode, dan pekerjaan secara umum) tidak tercapai. Bagaimanapun, penggunaan templat membutuhkan upaya tambahan. Kira-kira sama dengan pengujian Unit.

Saya akan mencoba menjelaskan pola desain dalam hal cara menerapkannya, di mana dan mengapa.

Enam generator dapat dikaitkan dengan:

• Prototipe
• Pabrik Abstrak,
• Metode Pabrik
• Pembangun
• Singleton
• Inisialisasi malas.

Semua pola lain yang berhubungan dengan generator adalah kasus aplikasi khusus dan tidak ada gunanya memikirkannya.

Membangkitkan pola dapat dibagi menjadi tiga kelompok, pada pertanyaan yang mereka jawab. Jadi, tiga pertanyaan:

• Dimana?
• Bagaimana?
• Kapan?

Dimana?

Tiga pola menjawab pertanyaan ini: Prototipe, Pabrik Abstrak, dan Metode Pabrik.

Sebenarnya, pola-pola ini menentukan tempat generasi. Selain itu, mereka terhubung secara hierarkis dan memiliki cakupan yang berbeda. Koneksi ditunjukkan pada gambar, panah menentukan arah panggilan.

Dalam implementasinya, "Metode Pabrik" dapat mendelegasikan pembuatan instance ke "Pabrik" yang ada atau "Prototipe". "Prototipe", bagaimanapun, tidak harus bergantung pada siapa pun dan melakukan semuanya sendiri. Sekarang lebih detail.

"Prototipe"

Templat ini sesuai dengan tempat "Produk", pada kenyataannya, adalah pembangun kelas. Dengan demikian, turunan dari kelas tertentu (yang sebelumnya dikenal) selalu dihasilkan.
Dalam kerangka templat ini, perancang hanya tahu parameter yang diteruskan langsung ke sana (jumlah parameter cenderung ke jumlah bidang kelas). Tentu saja, ada akses penuh ke semua bidang dan properti dari kelas yang dibuat.

Metode "Prototipe" yang diterapkan dengan benar memungkinkan Anda untuk menyingkirkan metode inisialisasi tambahan di depan umum. Pada gilirannya, antarmuka eksternal kelas menjadi lebih mudah dan kurang menggoda untuk menggunakan kelas untuk tujuan lain.

Apa yang diberikan template ini kepada kami:

• Konektivitas rendah - kelas hanya tahu sendiri, tidak tergantung pada data eksternal;
• Extensibility - konstruktor dapat didefinisikan ulang atau ditambahkan ke turunan;

Dari minus:

• Untuk kelas kompleks, Anda mungkin perlu melewati banyak parameter untuk inisialisasi. Meski ada solusi sepele.
• Penggunaan langsung pada Klien dapat mengganggu keterbacaan dan secara praktis memblokir kemungkinan mengganti jenis instance yang dihasilkan dalam turunan Klien.

Template paling populer. Semua orang menggunakannya, tetapi sedikit yang tahu apa yang digunakannya. Itu bagus sampai model kerja pertama diperoleh, sampai kelas dan hubungannya benar-benar ditentukan. Setelah itu, pemrosesan dan peningkatan abstraksi adalah wajib.

"Pabrik abstrak"

Beberapa mitra kelas. Itu bisa khusus, atau "menggabungkan". Mungkin statis (tidak ada instance). Contoh "menggabungkan" bisa menjadi kelas konfigurasi. Mungkin juga tersembunyi di balik Fasad.

"Factory" biasanya melihat semua pengaturan global aplikasi (atau subsistem terpisah). Generasi segera dapat didelegasikan ke Prototipe. Dalam hal ini, jumlah parameter input dalam metode Pabrik akan kurang dari pada konstruktor Prototipe yang sama. Pabrik tidak memutuskan siapa yang akan dibuat berdasarkan parameter yang masuk.

Template ini sangat nyaman dan mudah diimplementasikan, tetapi membutuhkan desain awal. Jika Anda membuat pabrik untuk semuanya, ini akan menyulitkan kode. Faktanya, kita mendapatkan analog dari Prototipe, tetapi pindah ke kelas pihak ketiga.

Dari pro:

• Redefinisi yang baik dalam keturunan
• Panggilan yang disederhanakan
• Atas dasar Pabrik, mudah untuk menerapkan substitusi (template Negara)

Namun ada juga kelemahannya:

• Ini membutuhkan desain, terutama untuk pabrik universal (yang digunakan dalam banyak proyek). Dengan kata lain, mendapatkan pabrik yang baik segera tidak mudah.
• Sangat mudah untuk mengacaukan kode, ada dua area utama:
  
  • Geser ke arah Prototipe, tetapi di kelas luar. Metode kelebihan beban dengan parameter, ada banyak metode sendiri. Akibatnya, warisan sulit, baik di Pabrik itu sendiri maupun di Klien.
  • Pabrik dengan metode universal. Metode ini mengembalikan contoh apa pun tergantung pada parameter yang dikirimkan. Hasilnya, seperti pada kasus pertama.
  
  

Sangat populer Template ini digunakan oleh mereka yang menghadiri kursus GoF. Sebagai aturan, kode menjadi lebih buruk daripada "sebelum menerapkan templat".

Masuk akal ketika Pabrik muncul selama pengerjaan ulang kode pertama. Pada tahap ini, kombinasi parameter untuk instance yang dibuat sudah diketahui, dan tidak akan sulit untuk menulis metode Pabrik umum. Akibatnya, panggilan di Klien akan disederhanakan.

Dalam beberapa kasus, lebih mudah menyembunyikan pabrik di belakang fasad. Misalnya, aplikasi memiliki selusin pabriknya, dan selusin perpustakaan. Bagi mereka, Anda dapat membangun fasad. Ini akan memungkinkan tidak menghubungkan perpustakaan ke setiap modul, dan juga mudah untuk mengganti satu pabrik dengan yang lain.

Metode Pabrik

Bagian atas abstraksi dalam pola generatif. Tempat Pelanggan asal. Kelas di mana setiap produk ditempatkan di Metode Pabrik memiliki setiap kesempatan seumur hidup. Jika tanpa fanatisme, maka poros pengembangan yang diasumsikan harus berdasarkan pada templat ini.

Metode pabrik tidak melihat di luar kelasnya. Jumlah parameter yang ditransmisikan secara langsung harus minimal (dalam batas nol). Metode itu sendiri harus dibangun dengan mempertimbangkan kemungkinan tumpang tindih pada keturunan.

Kesalahan umum adalah inisialisasi yang rumit dalam satu metode. Misalnya, saat membuat turunan yang kompleks (Templat pembuat), pembuatan semua bagian dari objek masa depan ditempatkan dalam satu metode. Akibatnya, metode seperti itu sulit untuk tumpang tindih dalam keturunan.

Dari pro:

• Akan mudah untuk mencocokkan metode templat templat
• Kami mendapatkan kode ringkas di mana logika terlihat jelas (tidak perlu dilihat di antara tumpukan metode dan parameter)

Pada dasarnya tidak ada kontra.

Template ini hampir tidak pernah digunakan. Sebagai aturan, itu hanya dapat dilihat dalam proyek dengan elaborasi awal yang mendalam. Ideal ketika Metode Pabrik mendelegasikan pembuatan ke "Pabrik" atau "Prototipe."

Contoh kecil

Kami memiliki kelas untuk masuk ke file di hard drive. Ini adalah bagaimana metode umum dalam Pola "Di mana?" Mungkin terlihat:

Prototipe:

constructor Create(aFilename: string; aLogLevel: TLogLevel); 

Semua yang harus diketahui oleh perancang diteruskan kepadanya dalam bentuk parameter.

Pabrik:

 function GetLogger(aLogLevel: TLogLevel): ILogger; 

Pabrik tahu file yang akan ditulis, seperti ditentukan dalam pengaturan aplikasi.

Metode pabrik:

 function NewLogger: ILogger; 

Di kelas Klien, diketahui dengan detail apa yang dicatat.

Dalam desain ini, untuk mengganti kelas logging dengan sebuah rintisan, itu sudah cukup untuk mendefinisikan kembali NewLogger di keturunan klien. Ini berguna saat melakukan tes Unit.

Untuk masuk ke basis data, cukup dengan mengganti metode GetLogger di turunan dari Pabrik.