Menggunakan OOP dalam tema

36

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?

themes php oop onetrickpony
sumber
5
@Ambitious Amoeba - Bisakah Anda menjelaskan mengapa Anda percaya bahwa menggunakan kelas untuk plugin untuk meminimalkan tabrakan namespace adalah konyol? Adapun tema mungkin akan sangat membantu juga jika Anda bisa memberikan contoh apa yang Anda anggap kode yang baik dalam tema dan apa yang Anda anggap tidak perlu. Membahas hal ini secara abstrak kemungkinan tidak akan mencapai wawasan apa pun untuk Anda atau orang lain, terutama orang lain yang tidak terbiasa dengan apa yang Anda maksud.
MikeSchinkel
1
Saya menggunakan kelas di mana pun saya bisa secara pribadi, jauh lebih mudah bagi saya untuk memelihara, memperbarui dan menggunakan kembali. Di samping preferensi pribadi, alasan bagus apa yang ada untuk menggunakan kelas?
t31os
1
Aneh, baru saja kehilangan komentar asli saya (bug SE mungkin?) .. saya akan mengulanginya, apa alasan bagus untuk tidak menggunakan kelas?
t31os
2
@MikeSchinkel: Anda dapat melakukannya dengan menambahkan awalan ke nama fungsi. Saya tidak berpikir itu layak overhead kelas tambahan hanya untuk memiliki nama fungsi yang bagus. Pokoknya, saya ingin tahu mengapa tema melakukan ini, tidak banyak tentang plugin
onetrickpony
4
@Ambitious Amoeba - Saya pasti akan memberikan bahwa Anda memiliki hak untuk pendapat Anda, tetapi pendapat saya berbeda. Saya percaya bahwa kejelasan bahwa kelas membawa ke kode dengan meminimalkan fungsi mengambang di namespace global adalah layak apa yang saya yakini sebagai jumlah overhead tambahan yang efektif tak terukur, terutama ketika menggunakan IDE tingkat profesional seperti PhpStorm. Dan kelas membuat unit mandiri sehingga pengembang dapat mengetahui kode apa yang dibutuhkan modul. Dan akhirnya setelah mengembangkan gaya plugin WordPress saya untuk menggunakan kelas, metode lain hanya terasa bagiku seperti pengkodean yang ceroboh.
MikeSchinkel

Jawaban:

26

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).

EAMann
sumber
Saya tidak setuju dengan bagian "ekstensibilitas". Anda memiliki tingkat kontrol yang sama atas tema induk seperti yang Anda lakukan jika Anda menggunakan tindakan dan fungsi khas Anda. Mengapa? Anda mengatakannya sendiri, ini tidak benar OOP. Saya juga tidak setuju dengan namespacing - inilah mengapa saya memulai pertanyaan ini di tempat pertama - Cobalah mendefinisikan ulang fungsi apa pun dari Hybrid di plugin apa pun dan Anda akan melihat bahwa fungsinya akan bertabrakan. Menurut Anda mengapa mereka masih menambahkan awalan? :) Anda tidak dapat membungkus seluruh tema dalam satu kelas, hanya saja tidak masuk akal ...
onetrickpony
Saya tidak mengatakan untuk tidak menggunakan OOP dalam tema, seperti beberapa orang di sini mungkin mengerti, sebaliknya (lihat 2,8 widget untuk misalnya., Pejalan kaki dll), tetapi tidak seperti ini.
onetrickpony
1
Sepertinya Anda memiliki masalah dengan implementasi spesifik Hybrid, bukan dengan praktik menggunakan OOP dalam tema atau bahkan menggunakan kelas untuk namespace fungsi yang ditentukan dalam tema. Saya mencoba menjawab pertanyaan Anda yang lebih luas. Mengapa ini? dan ulang: apa keuntungan melakukan ini? Saya tidak akan menghabiskan waktu membela apa yang tampak sebagai implementasi setengah hati atau berdebat melawan permusuhan Anda yang jelas terhadap struktur kerangka tema tertentu. Intinya, jika Anda tidak suka cara Hybrid dibangun, gunakan sesuatu yang lain.
EAMann
1
tidak sama sekali, saya suka Hybrid (tapi bukan hal kelas tentu saja). Hybrid membuat saya bersemangat untuk membuat kerangka tema sendiri. Ambil contoh lain, Suffusion, jenis latihan yang sama. Sekali lagi, ruang nama dalam kasus ini tidak berfungsi dengan tema, semua fungsi dalam kelas wrapper akan selalu bertentangan dengan plugin, karena plugin dimuat oleh WP "di dalam" tema.
onetrickpony
1
Cukup adil. Coba ingat-ingat bahwa sebagian besar pekerjaan WP bukan OOP (karena WP tidak), tetapi menempatkan metode tema di kelas untuk meniru bagaimana hal itu dilakukan dalam sebuah plug-in setidaknya merupakan langkah di kanan arah ... bahkan jika itu adalah kelas yang setengah dipahami dan diimplementasikan dengan buruk. Saya pasti setuju bahwa hanya membungkus segala sesuatu di kelas dan memanggil sesuatu secara prosedural agak aneh (dan tidak berguna dari POV pengembang pihak ke-3 yang mencoba menggunakan sistem). Tetapi jika dilakukan dengan benar (dan dalam Hibrid sepertinya tidak), mengklarifikasi kode Anda di kelas functions.phpbisa sangat kuat.
EAMann
29

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
fuxia
sumber
1
Adakah peluang untuk mendapatkan kelas 'tema' Anda? Saya ingin menulis sendiri dan saya ingin tahu bagaimana Anda melakukannya.
Horttcore
1
Saya belum memutuskan ini. Mungkin saya sedang merealisasikan tema dasar baru bersama dengan @bueltge tahun depan yang menggunakan beberapa kelas ini. Sangat mungkin tidak sebelum pawai, saya khawatir.
fuxia
5
Khusus untuk kasus Anda, tema dan kerangka kerja gratis, OOP adalah cara yang harus dilakukan. Orang lain harus bekerja dengan kode-kode ini. Penulis harus membuat proses ini semudah dan sefleksibel mungkin. Mengganti kelas lebih mudah daripada mengganti 20 fungsi, karena kelas yang ditulis dengan baik memiliki API yang jelas.
fuxia
2
Saya tidak bisa mengatakan apa-apa tentang Hybrid; Saya tidak pernah menggunakannya. Tapi, ya, pengontrol yang mengatur segala sesuatu di balik tirai, menawarkan filter yang baik dan memasukkan beberapa pola MVC ke dalam kekacauan tema yang biasa - adalah A Good Thing. Jangan percaya padaku. Cobalah. :)
fuxia
3
Sudah saatnya, WordPress membutuhkan tema OOP untuk pengembang; Saya harap kita mencari waktu untuk bekerja demi tujuan kita. Kutipan kecil di sini dan manfaatnya menunjukkan kemungkinan besar dengan oop untuk tema pelanggan; cara cepat untuk mewujudkan tema baru dan juga bagus untuk pemeliharaan.
bueltge
3

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.

kaisar
sumber
2

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.

Tex
sumber
1
Blog terbuka untuk pengguna "yang diundang" saja, sayangnya. Hanya pengingat lain mengapa kita tidak boleh memposting informasi kita pada layanan gratis dan, sebaliknya, harus meng-host blog kita sendiri. Facebook hampir sama dalam hal ini. Tautan sumber daya yang diperbarui akan menyenangkan. FWIW Saya telah melihat sisi gelap dari OOP dan tidak akan pernah menggunakannya lagi kecuali itu benar-benar diperlukan dalam konteksnya, karena fungsi tingkat tinggi biasanya dapat memperluas fungsionalitas dan membantu mengurangi pelat lantai dan penyalahgunaan classkata kunci.
Josh Habdas
2

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.

Jester831
sumber
-4

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" ...

Menandai
sumber
10
Pertanyaan ini tidak mengeluh tentang kode, itu meminta penjelasan yang jelas tentang mengapa kode akan ditulis dengan cara tertentu. Sebagian besar WP core bersifat prosedural, dengan beberapa fitur baru menggunakan pendekatan OOP. Banyak plug-in modern juga menggunakan OOP untuk merangkum fungsionalitas. Tetapi kebanyakan tema tidak. OP bertanya mengapa pendekatan pseudo-OOP akan digunakan dan memberikan Hybrid sebagai contoh. Anda tidak menjawab pertanyaan, Anda mengoceh.
EAMann