Temalarda OOP kullanımı

Gerçekten gerekli olmadığında nesne yönelimli kodlamayı kullanan pek çok eklenti görüyorum.

Ancak daha da kötüsü, tema geliştiricilerin de aynı şeyi yapmaya başladıkları. Ticari temalar ve Suffusion gibi ücretsiz popüler temalar, en sevdiğim tema bile - Hibrit, tüm işlevlerini bir sınıf içinde doldurur, onu bir kez işlev.php'de başlatır ve işlevlerini usule uygun bir şekilde çalıştırır :)

O ne lan? Bunu yapmanın amacı ne? Açıkçası, aynı temanın iki veya daha fazla örneğini aynı anda kullanmayacaksınız.

Eklentilerin ad alanı için (saçma) bunu yaptığını varsayalım, ama mazeret nedir? Bir şey mi eksik?

Böyle bir temayı kodlamanın avantajı nedir?

Verdiğiniz örneğe dayanarak kafanızdaki karışıklığı anlayabiliyorum. Bu, bir sınıfı kullanmanın gerçekten kötü bir yolu ... ve sadece bir sınıf kullanıldığı için, bir sistem OOP'si yapmıyor.

Hibrit durumunda, işlevlerini adlandırmak için sadece bir sınıf kullanıyorlar. Hybrid'in bir tema çerçevesi olduğu düşünüldüğünde , bu, çocuk temalarının geliştiricinin isim çarpışması konusunda endişelenmeden fonksiyon isimlerini tekrar kullanabilmeleri için yapılır. Çoğu durumda, bir tema çerçevesi (ana tema) çok karmaşıktır, çoğu çocuk tema geliştiricisi kaputun altında ne olup bittiğini tam olarak anlayamaz.

Hybrid bir sınıf yapısı kullanmadıysa, alt tema geliştiricilerin mevcut tüm işlev çağrılarının ne olduğunu bilmeleri gerekir; böylece adları yeniden kullanmaktan kaçınabilirler. Ve evet, tüm fonksiyonlarınızı benzersiz bir sümüklü böcek ile öneklendirebilirsiniz, ancak aynı işlevselliği kullanmak isteyen başka sistemler geliştirmeniz durumunda kodun okunmasını zorlaştırması, bakımı zor ve doğal olarak tekrar kullanılamaz olması gerekir.

Sorularınıza Cevap Vermek İçin

O ne lan? Bunu yapmanın amacı ne? Açıkçası, aynı temanın iki veya daha fazla örneğini aynı anda kullanmayacaksınız.

Hayır, aynı temanın iki veya daha fazla örneğini kullanmayacaksınız. Fakat dediğim gibi, bu durumda sınıf yapısını, geleneksel bir nesne örneği oluşturmadan, işlevleri isimlendiren bir ad olarak düşünün . Her şeyi bir sınıfta bir araya getirmek ve ya çağrı yöntemlerine ( myClass->method();) ya da doğrudan çağrı yöntemlerine ( ) çağrı yapmak myClass::method();, bir şeyi okunaklı, yeniden kullanılabilir bir şekilde adlandırmak için çok temiz bir yoldur.

Elbette myClass_method();bunun yerine her zaman böyle bir şey kullanabilirsiniz , ancak bu kodun herhangi birini başka bir temada, bir eklentide veya başka bir çerçevede tekrar kullanmak istiyorsanız geri dönüp tüm öneklerinizi değiştirmeniz gerekir. Her şeyi bir sınıfta tutmak daha temizdir ve çok daha hızlı bir şekilde yeniden geliştirmenize ve yeniden konuşlandırmanıza izin verir.

Eklentilerin ad alanı için (saçma) bunu yaptığını varsayalım, ama mazeret nedir? Bir şey mi eksik?

Çoğu durumda sizinle aynı fikirdeyim. Ancak, bu çoğunluk hızla azalmaktadır. MultiSite kurulumunda aynı temanın varyasyonlarını kullanan birkaç site barındırıyorum. Küçük temalarla aynı temayı tekrar tekrar oluşturmak yerine, ana tema için tek bir "sınıfım" var ve tüm çocuk temaları o sınıfı genişletiyor. Bu, tüm ağ boyunca genel bir tekdüzelik duygusunu korurken, her site için özel işlevler tanımlamamı sağlıyor.

Bir yandan, tema geliştiricileri işlevlerini isimlendirmek için sınıf tabanlı bir yaklaşım seçebilirler (aynı kod parçalarını tekrar tekrar kullandığınız bir ortamda çalışıyorsanız saçma değildir). Öte yandan, tema geliştiriciler, alt temalar tarafından kolay genişletilebilirlik için sınıf tabanlı bir yaklaşım seçebilirler.

Böyle bir temayı kodlamanın avantajı nedir?

Sitenizde yalnızca Hybrid kullanıyorsanız, son kullanıcı olarak sizin için avantajı çok azdır. Hybrid için bir çocuk teması oluşturuyorsanız, adlandırma ve genişletilebilirliğin avantajları vardır. ThemeHybrid için çalışıyorsanız , avantaj, diğer projelerinizde (Prototip, Leviathan, vb.) Hızlı ve verimli kod kullanımında yatmaktadır.

Ayrıca, Hybrid'in belirli bir özelliğini seven ancak tüm temayı beğenmeyen bir tema geliştiricisiyseniz, avantaj, Hibrit olmayan projenizde (GPL olduğu varsayılarak) hızlı ve verimli bir kod kullanımında yatmaktadır.

hız

Mevcut temel temamın 13 sınıfı var. Yeni bir tema oluştururken bu sınıfları olduğu gibi kullanırım veya genişletirim. Bu sistem yeni bir tema oluşturma sürecini çok, çok hızlı bir hale getiriyor.

Sıkı kapsamları

Nadiren global değişkenlere ihtiyacım var, çünkü kodumun bilmesi gereken her şey sınıf üyelerinde gizli. Bu yüzden, çok az farklı iki filtre veya eylem arasında bir değişkeni, kötü yazılmış eklentilerle çarpışma riski olmadan paylaşabiliyorum.

Bakım

Her sınıf bir dosyadır. Bir müşterinin temasını güncellemem gerekirse, sadece bazı dosyaları güncellerim. Aynı API'yi sunduğum sürece, sınıfların içinde ne olursa olsun bana kalıyor.

Örnek: comment_form();çağrının üstünde, basit bir işlem kullanıyorum:

do_action( 'load_comment_class' );
comment_form();

Hangi yorum sınıfının yükleneceği denetleyicime karar veriyor. Yorum sınıfında tam olarak ne olacağı bireysel sınıfa karar verir.

Bunu saf bir prosedürel yaklaşımla dene ve çıldırıyorsun. :)

Okunabilirlik

Her şeyi kendi görevine ayırdıysanız , birkaç ay sonra kendi kodunuzu yeniden okumak ve anlamak çok daha kolaydır .

Yararlı sınıf hiyerarşileri için bazı örnekler

• Meta_Box-> tarafından genişletildi Shortdesc_Meta_Boxve Simple_Checkbox_Meta_Box-> tarafından genişletildiSidebar_Switch
• User_Profile_Addon-> tarafından genişletildi User_Profile_Checkbox(bkz. Soru 3255 )
• Comment_Form -> tarafından genişletildi {$theme_name}_Comment_Form

Dikkate alınması gereken bir başka nokta: Hız.

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

Kısa bir bakış / çıktıdan sonra ~ 1.700 dahili fonksiyon ve ~ 1.400 kullanıcı fonksiyonunu = ~ 3.100 / 3.200 fonksiyonunu VS buldum. ~ 250 Sınıflar. Sanırım bu bir araştırmaya ne kadar ihtiyaç duyulacağı hakkında en çok şey söylüyor. !function_exists('')Temanızda yaklaşık 50-100 işlev ararsanız ... sadece biri için bir zamanlayıcı ayarlayın ve sonra biraz matematik yapmaya başlayın. OOP olmasa bile kod yazmanın iyi bir yolu

1) yeniden kullanılabilir
2) bakım yapılabilir
3) değiştirilebilir
4) biraz daha hızlı

Hızlı bir şekilde meta kutuları, widget'lar vb. Yapmanıza yardımcı olan Web'de dolaşan farklı sınıflara göz attığınızda, o zaman @toscho gibi bir denetleyici kullanmak iyidir, çünkü sınıfları takıp çıkartabilirsiniz ve sadece yerine denetleyicideki sınıflarınızı idare eden bazı çizgiler.

Bazıları, kapsüllemenin, OOP'un sunduğu tek (veya en azından birincil) fayda olduğunu ve miras ve devletin sıkıcı ve kötü arasında bir yerde olduğunu iddia ediyor:

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

Yazar, sınıfları / nesneleri statik işlevler için kapsayıcılardan çok yapı olarak kullanmaktan bahsediyor, ancak tamamen OOP kampının dışında kalan birinden tamamen farklı bir soru okumak ilginç.

Bir sonraki WordPress Plugin'imi Haskell'e yazabilirim.

Ah oldukça tartışma! Kabul etmeliyim ki, kapsülleme için sınıfları kullanmayacağımı çok daha fazla. Buradaki eklentilerimdeki işlevlerimi bir sınıfa sarabildiğim düşüncesi ve bu sınıf içinde yazdığım diğer eklentiler arasında bile genel olan çok basit, anlamlı yöntem adları kullanıyor. Bu durumda, sınıflar 5.2.x ortamları için kaçınmak zorunda kaldığım ad alanlarının yerine geçiyor.

OOP'un modülerlik için faydalı olduğu birkaç örnek olsa da, işlevlerinizi sarmalamanın basit etkisi, ek bir eklenti genişletilebilirlik bonusu da yaratır. Örneğin, kısa bir süre önce sınıfa dayalı bir faturalama çözümünü genişlettim ve öyle ki ana sınıfı genişletebilir, çeşitli işlevlere (w / parent :: calls) ekstra kod ekleyebilir, hatta genişletilmiş eklentiyi içselleştirmeden işlevleri değiştirebilirim.

Olsa da, çoğu için sınıf sarma, sadece ad alanlarının yerine geçiyor.

Yazmadığınız kod hakkında şikayetçi olmanızın amacı nedir?

Eğer kodu beğenmediyseniz, kendinize bir tane yazın!

Basit. Sorun çözüldü.

Programcılar işleri yapmaktan hoşlanırlar. Bu yüzden, onlara nasıl kod yazacaklarını, ne tür bir viski içileceğini, hangi sigara içileceğini ya da hangi dinin izleneceğini söyleyebileceğinizi düşünmeyin. Sadece bu tür bir ayıklama hata ayıklamak ve istediklerini yapma hakkını devam edecektir. ;-)

Kod şiir değil. Code, Sinatra şarkısının "My Way" adlı bir varyasyonudur ...