Bagian 4 – WordPress dan Pemrograman Berorientasi Objek: Contoh WordPress – Desain

Pada titik ini, kami memiliki persyaratan yang jelas seperti yang dijelaskan di Bagian 3 dari seri ini (lihat di sini jika Anda melewatkannya).

Sekarang saatnya untuk mulai memikirkan desain plugin kami yang baru dan lebih baik!

Kami ingin mengingatkan Anda bahwa langkah ini mungkin memakan waktu lama ketika Anda mencobanya pada proyek Anda sendiri. Anda mungkin juga tidak akan mendapatkan semuanya dengan benar untuk pertama kalinya. Kemungkinan Anda akan datang dengan desain, mulai menerapkannya, dan kemudian menyadari bahwa Anda harus kembali dan memikirkan kembali pendekatan Anda.

Ini benar-benar sepadan dengan usaha, jadi luangkan waktu sebanyak yang diperlukan untuk mendapatkan semuanya dengan benar. Proyek yang terstruktur dengan baik akan mempermudah pemeliharaan dan perluasannya, dan bahkan menggunakan kembali kodenya di proyek lain sehingga dalam jangka panjang ini merupakan penggunaan waktu yang baik.

Selanjutnya, kami akan fokus pada beberapa bagian penting dari plugin dan mendiskusikan bagaimana kami membuat desain kami.

Membedah Halaman Pengaturan

Mari kita lihat lebih dekat halaman admin plugin.

Anda akan melihat bahwa ada judul ("Batasi Pengaturan Upaya Masuk"), beberapa bagian yang berisi beberapa bidang, dan tombol "Ubah Opsi" di bagian bawah halaman.

Setiap bagian terdiri dari judul, seperti "Statistik", dan beberapa bidang.

Setiap bidang memiliki judul di sebelah kiri, dan konten lainnya di sebelah kanan. Ada bidang teks, tombol radio dan kotak centang dan, beberapa di antaranya, seperti "Penguncian Total", hanya menampilkan informasi dan tidak dapat diubah langsung oleh pengguna admin.

Beberapa bidang juga menyertakan deskripsi, seperti bidang "Sambungan Situs", tetapi tidak semuanya.

Dengan mengingat hal di atas, kita harus memecahnya menjadi potongan-potongan konseptual yang nantinya akan menjadi kelas.

API Pengaturan WordPress memungkinkan kita untuk mendaftarkan halaman pengaturan, bagian di dalam halaman tersebut dan bidang di dalam bagian:

Halaman → Bagian → Bidang

Kami berpikir, mengapa tidak menambahkan satu "lapisan" lagi, Elemen, untuk membuat plugin kami lebih mudah diperluas di masa mendatang.

Halaman → Bagian → Bidang → Elemen

Jadi, Halaman dan Bagian adalah apa yang telah kami jelaskan di atas, dan Bidang akan berisi Elemen dari jenis konten apa pun di sisi kanan.

Dengan mempertimbangkan semua jenis elemen yang berbeda ini, kami menggunakan kelas Element dan beberapa kelas, memperluasnya, untuk kotak centang, tombol radio, angka, dll. yang akan menghasilkan keluaran yang berbeda.

Kami mungkin juga perlu menambahkan lebih banyak halaman dan bagian di masa mendatang. Jadi sepertinya kita perlu memperluas halaman admin dan kelas bagian ini.

Hal yang sama berlaku untuk ladang. Kelas untuk "Penguncian total", "Penguncian aktif", dll. Akan memperluas kelas (induk) yang sama.

Berikut adalah visual sederhana yang menunjukkan hubungan tersebut:

Tentu saja, tidak semua "komponen" termasuk dalam diagram.

Struktur seperti ini membuat plugin lebih mudah diperluas; kita dapat dengan mudah menambahkan bidang, elemen, atau bagian jika diperlukan. Kita akan dapat dengan mudah menambahkan lebih banyak komponen—bidang, elemen, atau bagian—dengan membuat kelas turunan baru, tanpa harus mengubah yang sudah ada.

Berpikir dan Abstrak

Sekarang adalah saat yang tepat untuk mulai memikirkan apa yang dilakukan berbagai komponen plugin kita. Selama fase desain, kita tidak perlu membahas banyak detail tentang cara kerja sesuatu.

Misalnya, pertimbangkan semua elemen, tabel, statistik, dan hampir semua hal lain yang akan ditampilkan kepada pengguna. Mereka mungkin merupakan komponen terpisah tanpa kesamaan, tetapi semuanya pada akhirnya akan menghasilkan beberapa keluaran. Oleh karena itu, beberapa fungsi akan umum untuk komponen yang sama sekali tidak terkait. Tentu saja, ini meluas ke seluruh komponen kami juga.

Dalam visual di atas, kita melihat bagaimana antarmuka UI diimplementasikan oleh beberapa kelas.

Perhatikan fakta bahwa antarmuka UI diimplementasikan oleh kelas Statistik, Log Penguncian, Tabel, dan Elemen yang disebut sebagai kelas induk . Tidak perlu kelas Radio/Nomor/Elemen Kotak Centang untuk mengimplementasikan antarmuka secara langsung, karena mereka mewarisi semua antarmuka dari kelas induknya. Namun, kelas anak dapat menimpa metode kelas induknya.

Karena kita tahu bahwa plugin kita akan menangani pengaturan, kita dapat dengan aman berasumsi bahwa kita akan membaca dan menulis nilainya. Artinya, bisa mendapatkan , mengatur , dan menghapus opsi.

Semua tindakan ini akan digabungkan bersama dalam sebuah kelas. Kami mungkin akan menyimpan opsi kami di database WordPress atau semacamnya. Untuk saat ini, kita tidak perlu peduli tentang bagaimana atau di mana kita akan menyimpan data kita.

Kami dapat menyimpan abstraksi opsi get/set/remove dalam pikiran kami, menyederhanakan berbagai hal secara konseptual, dan terus mendesain plugin kami.

File Plugin Utama

Di sini, kami akan memberikan beberapa informasi tentang plugin ke WordPress melalui komentar header dan melakukan beberapa inisialisasi. Kami akan mengatur kode kami, dengan membungkus semuanya dalam kelas kecil.

Bergantung pada bagaimana kelas plugin kita akan bekerja bersama, kelas utama harus membuat instance sebagian besar dari mereka. Sejauh yang kami tahu, ini akan mencakup kelas yang terkait dengan opsi, halaman admin, percobaan ulang, dan penguncian.

Kelas Potensial

Kami meluangkan waktu untuk mencoba dan mencari tahu kelas apa yang akan kami butuhkan dan kami berakhir dengan daftar sebagai berikut:

• Coba lagi
• Lockout
• Kue
• Pesan kesalahan
• Notifikasi email
• pemberitahuan admin
• tombol
• Log penguncian
• Penguncian Aktif/Total
• alamat IP

Ingatlah bahwa tidak ada satu cara yang "benar" untuk menyusun plugin Anda. Seperti kebanyakan hal dalam pengembangan perangkat lunak, ada beberapa, sama-sama valid, cara untuk memecahkan masalah.

Di bagian "Umum", misalnya, hubungan antara kelas kami akan terlihat seperti ini:

Bagian "Statistik" akan mirip dengan ini:

Akhirnya, "Log penguncian" akan sangat mirip dengan "Statistik":

Kesimpulan

Sejauh ini kami mendefinisikan persyaratan kami dan memikirkan desain untuk plugin kami yang baru dan lebih baik. Kami menjelaskan bagaimana kami membuat struktur kami dan juga menyediakan beberapa diagram sederhana yang menunjukkan bagaimana kelas kami akan terkait satu sama lain.

Klik di sini untuk membaca Bagian 5 dalam Seri Pemrograman Berorientasi Objek kami

Lihat juga

• WordPress dan Pemrograman Berorientasi Objek – Gambaran Umum
• Bagian 2 – WordPress dan Pemrograman Berorientasi Objek: Contoh Dunia Nyata
• Bagian 3 – WordPress dan Pemrograman Berorientasi Objek: Contoh WordPress – Mendefinisikan Ruang Lingkup