Menggunakan OOP dalam tema

Saya melihat banyak plugin menggunakan pengkodean berorientasi objek ketika sebenarnya tidak perlu.

Tetapi yang lebih buruk lagi adalah bahwa pengembang tema mulai melakukan hal yang sama. Tema komersial dan tema populer gratis seperti Suffusion, bahkan tema favorit saya - Hibrid, memasukkan semua fungsi mereka di dalam kelas, instantiate sekali dalam functions.php dan jalankan fungsinya secara prosedural :)

Wtf? Apa gunanya melakukan ini? Jelas Anda tidak akan menggunakan dua contoh atau lebih dari tema yang sama, pada saat yang sama.

Mari kita asumsikan bahwa plugin melakukan ini untuk namespace (yang konyol), tapi apa alasan temanya? Apakah saya melewatkan sesuatu?

Apa keuntungan dari pengodean tema seperti ini?

Saya dapat memahami kebingungan Anda berdasarkan contoh yang Anda berikan. Itu benar-benar cara yang buruk untuk menggunakan kelas ... dan hanya karena kelas digunakan, tidak membuat sistem OOP.

Dalam kasus Hybrid, mereka hanya menggunakan kelas untuk namespace fungsinya. Mengingat Hybrid adalah kerangka kerja tema , ini dilakukan agar tema anak dapat menggunakan kembali nama fungsi tanpa pengembang harus khawatir tentang tabrakan nama. Dalam banyak kasus, kerangka kerja tema (parent theme) sangat kompleks, banyak pengembang tema anak tidak akan pernah mengerti persis apa yang terjadi di bawah tenda.

Jika Hybrid tidak menggunakan struktur kelas, pengembang tema anak perlu tahu apa semua panggilan fungsi yang ada sehingga mereka dapat menghindari penggunaan kembali nama. Dan ya, Anda bisa saja mengawali semua fungsi Anda dengan siput unik, tetapi itu membuat kode sulit dibaca, sulit untuk dipelihara, dan secara inheren tidak dapat digunakan kembali jika Anda mengembangkan sistem lebih lanjut yang ingin memanfaatkan fungsi yang sama.

Untuk Menjawab Pertanyaan Anda

Wtf? Apa gunanya melakukan ini? Jelas Anda tidak akan menggunakan dua contoh atau lebih dari tema yang sama, pada saat yang sama.

Tidak, Anda tidak akan menggunakan dua contoh atau lebih dari tema yang sama. Tapi seperti yang saya katakan, pikirkan struktur kelas dalam kasus ini sebagai penamaan fungsi, bukan membuat contoh objek tradisional. Melumpuhkan semuanya bersama-sama di dalam kelas dan membuat instance untuk memanggil metode ( myClass->method();) atau memanggil metode secara langsung ( myClass::method();) adalah cara yang sangat bersih untuk menamai hal-hal dengan cara yang dapat dibaca dan dapat digunakan kembali.

Tentu saja Anda selalu dapat menggunakan sesuatu seperti itu myClass_method();, tetapi jika Anda ingin menggunakan kembali salah satu kode ini di tema lain, dalam sebuah plug-in, atau dalam kerangka antoher Anda harus melihat kembali dan mengubah semua awalan Anda. Menjaga segala sesuatu di kelas lebih bersih dan memungkinkan Anda membangun kembali dan memindahkan kembali lebih cepat.

Mari kita asumsikan bahwa plugin melakukan ini untuk namespace (yang konyol), tapi apa alasan temanya? Apakah saya melewatkan sesuatu?

Dalam sebagian besar situasi saya setuju dengan Anda. Namun, mayoritas itu dengan cepat memudar. Saya meng-host beberapa situs pada instalasi MultiSite yang menggunakan variasi dari tema yang sama. Daripada menciptakan kembali tema yang sama berulang-ulang dengan perbedaan kecil, saya memiliki "kelas" tunggal untuk tema induk dan semua tema anak memperluas kelas itu. Ini memungkinkan saya untuk mendefinisikan fungsionalitas khusus untuk setiap situs sambil tetap mempertahankan rasa keseragaman secara umum di seluruh jaringan.

Di satu sisi, pengembang tema dapat memilih pendekatan berbasis kelas untuk namespace fungsionalitasnya (yang tidak konyol jika Anda bekerja di lingkungan di mana Anda menggunakan kembali potongan kode yang sama berulang-ulang). Di sisi lain, pengembang tema dapat memilih pendekatan berbasis kelas agar mudah dikembangkan oleh tema anak.

Apa keuntungan dari pengodean tema seperti ini?

Jika Anda hanya menggunakan Hybrid di situs Anda, ada sedikit yang tahu manfaatnya bagi Anda sebagai pengguna akhir. Jika Anda sedang membangun tema anak untuk Hybrid ada keuntungan dari penempatan nama dan ekstensibilitas. Jika Anda bekerja untuk ThemeHybrid , keuntungannya terletak pada penggunaan kembali kode yang cepat dan efisien di seluruh proyek Anda yang lain (Prototipe, Leviathan, dll).

Dan jika Anda adalah pengembang tema yang menyukai fitur spesifik Hybrid tetapi bukan keseluruhan tema, keuntungannya terletak pada penggunaan kembali kode yang cepat dan efisien dalam proyek non-Hibrid Anda (dengan asumsi itu juga GPL).

Kecepatan

Tema dasar saya saat ini memiliki 13 kelas. Ketika saya membangun tema baru, saya menggunakan kelas-kelas ini sebagaimana adanya atau saya memperluasnya. Sistem itu membuat proses membangun tema baru sangat, sangat cepat.

Lingkup ketat

Saya jarang membutuhkan variabel global, karena semua kode saya harus tahu tersembunyi di anggota kelas. Jadi saya dapat berbagi variabel antara dua filter atau tindakan yang sangat berbeda tanpa risiko tabrakan dengan plugin yang ditulis dengan buruk.

Pemeliharaan

Setiap kelas adalah satu file. Jika saya perlu memperbarui tema klien, saya hanya memperbarui beberapa file. Apa pun yang terjadi di dalam kelas tergantung pada saya selama saya menawarkan API yang sama.

Contoh: di atas comment_form();panggilan, saya menggunakan tindakan sederhana:

do_action( 'load_comment_class' );
comment_form();

Kelas komentar mana yang akan dimuat menentukan controller saya. Apa yang sebenarnya terjadi di dalam kelas komentar menentukan kelas individu.

Coba ini dengan pendekatan prosedural murni dan Anda akan gila. :)

Keterbacaan

Jauh lebih mudah untuk membaca ulang dan memahami kode Anda sendiri beberapa bulan kemudian jika Anda telah memisahkan semuanya dengan tugasnya.

Beberapa contoh untuk hierarki kelas yang berguna

• Meta_Box-> diperpanjang oleh Shortdesc_Meta_Boxdan Simple_Checkbox_Meta_Box-> diperpanjang olehSidebar_Switch
• User_Profile_Addon-> diperpanjang oleh User_Profile_Checkbox(lihat Pertanyaan 3255 )
• Comment_Form -> diperpanjang oleh {$theme_name}_Comment_Form

Poin lain yang perlu dipertimbangkan: Kecepatan.

if ( !class_exists('cccYourClassName') )  
// VERSUS  
if ( !function_exists('ccc_your_function_name') )

Setelah melihat sekilas / mencetak saya menemukan ~ 1.700 fungsi internal dan ~ 1.400 fungsi pengguna = ~ 3.100 / 3.200 fungsi VS. ~ 250 Kelas. Saya kira ini yang paling mengatakan tentang berapa banyak mencari akan perlu. Jika Anda memanggil !function_exists('')sekitar 50-100 fungsi dalam tema Anda ... cukup atur timer untuk satu dan kemudian mulai melakukan beberapa matematika. Meskipun bukan OOP, ini adalah cara yang baik untuk membuat kode

1) dapat digunakan kembali
2) dipelihara
3) dipertukarkan
4) sedikit lebih cepat

Ketika Anda melihat berbagai kelas yang beredar di web yang membantu Anda melakukan kotak meta, widget, dll dengan cepat, maka ada baiknya menggunakan pengontrol seperti @toscho yang disebutkan, karena Anda bisa cukup mencolokkan kelas dan masuk dan hanya mengganti beberapa baris di controller yang menangani kelas Anda.

Beberapa berpendapat bahwa enkapsulasi adalah satu-satunya (atau setidaknya manfaat utama) yang ditawarkan OOP, dan bahwa warisan dan status berada di suatu tempat antara membosankan dan jahat:

http://obiecte.blogspot.com/2008/09/oop-sucks.html

Penulis berbicara lebih banyak tentang menggunakan kelas / objek sebagai struct daripada sebagai wadah untuk fungsi statis, tetapi menarik untuk membaca pandangan yang sama sekali berbeda pada pertanyaan, dari seseorang yang tepat di luar kamp OOP.

Saya dapat menulis Plugin WordPress saya berikutnya di Haskell.

Oh cukup diskusi! Saya harus mengakui juga bahwa saya menggunakan kelas untuk enkapsulasi jauh lebih sering daripada tidak. Gagasannya adalah di sini bahwa di plugin saya, saya dapat membungkus fungsi saya di kelas, dan di dalam kelas itu menggunakan nama metode yang sangat sederhana dan bermakna yang umum bahkan di antara plugin lain yang saya tulis. Dalam contoh itu, kelas adalah pengganti ruang nama, yang terpaksa saya hindari untuk lingkungan 5.2.x.

Meskipun ada beberapa contoh bahwa OOP berguna untuk modularitas, tindakan sederhana membungkus fungsi Anda juga menciptakan bonus tambahan dari perluasan lintas-plugin. Sebagai contoh, saya baru-baru ini memperluas solusi faktur yang berbasis kelas, dan dengan demikian saya dapat memperluas kelas utama, menambahkan kode tambahan ke berbagai fungsi (w / parent :: calls) atau bahkan mengganti fungsi, semua tanpa menginternalisasi plugin yang diperluas.

Namun demikian, pembungkus kelas untuk sebagian besar hanyalah pengganti ruang nama.

Apa gunanya mengeluh tentang kode yang tidak Anda tulis?

Jika Anda tidak suka kode itu, tulis sendiri!

Sederhana. Masalah terpecahkan.

Programmer suka melakukan hal-hal dengan cara mereka. Jadi jangan anggap Anda bisa memberi tahu mereka cara menulis kode, jenis wiski apa yang harus diminum, jenis rokok apa yang harus dihisap, atau agama apa yang harus diikuti. Mereka hanya akan men-debug cacian tersebut dan terus melakukan apa yang mereka inginkan. ;-)

Kode bukanlah puisi. Code adalah variasi dari lagu Sinatra "My Way" ...