Verwenden von OOP in Themen

Ich sehe viele Plugins, die objektorientierte Kodierung verwenden, wenn es nicht wirklich notwendig ist.

Aber was noch schlimmer ist, ist, dass Theme-Entwickler dasselbe tun. Kommerzielle Themen und kostenlose beliebte Themen wie Suffusion, sogar mein Lieblingsthema – Hybrid, stopfen alle ihre functionen innerhalb einer class, instanziieren sie einmal in functions.php und führen ihre functionen in einer prozeduralen Weise aus 🙂

WTF? Was ist der Sinn dies zu tun? Natürlich werden Sie nicht zwei oder mehr Instanzen desselben Themas gleichzeitig verwenden.

Nehmen wir an, dass die Plugins dies für den Namensraum tun (was lächerlich ist), aber was ist die Ausrede des Themas? Fehle ich etwas?

Was ist der Vorteil eines solchen Themas?

Solutions Collecting From Web of "Verwenden von OOP in Themen"

Ich kann Ihre Verwirrung anhand des von Ihnen angegebenen Beispiels verstehen. Das ist wirklich ein schlechter Weg, um eine class zu verwenden … und nur weil eine class benutzt wird, macht sie kein System-OOP.

Im Fall von Hybrid verwenden sie nur eine class, um ihre functionen zu benennen. Wenn man bedenkt, dass Hybrid ein Themen- Framework ist , wird dies so gemacht, dass untergeordnete Themen functionsnamen wiederverwenden können, ohne dass sich der Entwickler um Namenskollisionen kümmern muss. In vielen Fällen ist ein Theme-Framework (Elternthema) so komplex, dass viele Entwickler von untergeordneten Themen niemals genau verstehen werden, was unter der Haube passiert.

Wenn Hybrid keine classnstruktur verwendet, müssen die Entwickler von untergeordneten Designs wissen, was alle vorhandenen functionsaufrufe sind, damit sie die erneute Verwendung von Namen vermeiden können. Und ja, Sie könnten einfach all Ihren functionen einen eindeutigen Slug voranstellen, aber das macht den Code schwer lesbar, schwer zu warten und von Natur aus nicht wiederverwendbar, sollten Sie weitere Systeme entwickeln, die die gleiche functionalität nutzen wollen.

Um deine Fragen zu beantworten

WTF? Was ist der Sinn dies zu tun? Natürlich werden Sie nicht zwei oder mehr Instanzen desselben Themas gleichzeitig verwenden.

Nein, Sie verwenden nicht zwei oder mehr Instanzen desselben Themas. Aber wie gesagt, denke an die classnstruktur in diesem Fall als Namespace für die functionen und nicht als traditionelle Objektinstanz. Wenn man alles in einer class zusammenfasst und es entweder in myClass->method(); ( myClass->method(); ) myClass::method(); oder Methoden direkt myClass::method(); ( myClass::method(); ), ist das eine sehr saubere Möglichkeit, Dinge lesbar und wiederverwendbar zu machen.

Natürlich könnte man immer etwas wie myClass_method(); Stattdessen, aber wenn Sie diesen Code in einem anderen Thema, in einem Plug-In oder in einem anderen Framework wiederverwenden möchten, müssen Sie alle Präfixe ändern und ändern. Alles in einer class zu halten ist sauberer und ermöglicht es Ihnen, viel schneller neu zu entwickeln und zu implementieren.

Nehmen wir an, dass die Plugins dies für den Namensraum tun (was lächerlich ist), aber was ist die Ausrede des Themas? Fehle ich etwas?

In den meisten Situationen würde ich dir zustimmen. Diese Mehrheit ist jedoch schnell im Schwinden begriffen. Ich hosten mehrere Websites auf einer MultiSite-Installation, die Variationen desselben Themas verwenden. Anstatt das gleiche Thema mit kleinen Unterschieden immer wieder neu zu erstellen, habe ich eine einzige “class” für das übergeordnete Thema und alle untergeordneten Themen erweitern diese class. Dadurch kann ich für jede Site benutzerdefinierte functionen definieren und gleichzeitig ein einheitliches Gefühl der Einheitlichkeit im gesamten Netzwerk aufrechterhalten.

Auf der einen Seite können Themenentwickler einen klassenbasierten Ansatz zum Namespace ihrer functionalität wählen (was nicht lächerlich ist, wenn Sie in einer Umgebung arbeiten, in der Sie immer wieder Teile desselben Codes verwenden). Auf der anderen Seite können Themenentwickler einen klassenbasierten Ansatz zur einfachen Erweiterbarkeit durch untergeordnete Themen auswählen.

Was ist der Vorteil eines solchen Themas?

Wenn Sie Hybrid nur auf Ihrer Website verwenden, gibt es für Sie als Endbenutzer wenig Vorteile. Wenn Sie ein untergeordnetes Thema für Hybrid erstellen, ergeben sich Vorteile durch Namensraum und Erweiterbarkeit. Wenn Sie für ThemeHybrid arbeiten , liegt der Vorteil in der schnellen und effizienten Wiederverwendung von Code in Ihren anderen Projekten (Prototype, Leviathan usw.).

Und wenn Sie ein Theme-Entwickler sind, der eine spezifische function von Hybrid, aber nicht das gesamte Theme mag, liegt der Vorteil in der schnellen, effizienten Code-Wiederverwendung in Ihrem nicht-hybriden Projekt (vorausgesetzt, es ist auch GPL).

Geschwindigkeit

Mein aktuelles Basisthema hat 13 classn. Wenn ich ein neues Thema erstelle, verwende ich diese classn entweder so wie sie sind oder erweitere sie. Dieses System macht den Aufbau eines neuen Themas sehr, sehr schnell.

Enge Bereiche

Ich brauche selten globale Variablen, weil alles, was mein Code wissen muss, in classnmitgliedern verborgen ist. So kann ich eine Variable zwischen zwei sehr unterschiedlichen Filtern oder Aktionen teilen, ohne das Risiko einer Kollision mit schlecht geschriebenen Plugins.

Instandhaltung

Jede class ist eine Datei. Wenn ich das Thema eines Clients aktualisieren muss, aktualisiere ich einfach einige Dateien. Was auch immer in den classn passiert, bleibt mir überlassen, solange ich dieselbe API anbiete.

Ein Beispiel: über dem comment_form(); Rufen Sie an, ich benutze eine einfache Aktion:

 do_action( 'load_comment_class' ); comment_form(); 

Welche Kommentarklasse geladen wird, entscheidet mein Controller. Was genau in der Kommentarklasse passiert, entscheidet über die einzelne class.

Versuchen Sie dies mit einem rein prozeduralen Ansatz und Sie werden verrückt. 🙂

Lesbarkeit

Es ist so viel einfacher, Ihren eigenen Code einige Monate später erneut zu lesen und zu verstehen, wenn Sie alles durch seine Aufgabe getrennt haben.

Einige Beispiele für nützliche classnhierarchien

  • Meta_Box -> erweitert um Shortdesc_Meta_Box und Simple_Checkbox_Meta_Box -> erweitert um Sidebar_Switch
  • User_Profile_Addon -> erweitert um User_Profile_Checkbox (siehe Frage 3255 )
  • Comment_Form -> erweitert um {$theme_name}_Comment_Form

Ein weiterer Punkt, den es zu beachten gilt: Geschwindigkeit.

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

Nach einem kurzen Blick / Ausdruck fand ich ~ 1.700 interne functionen und ~ 1.400 Benutzerfunktionen = ~ 3.100 / 3.200 functionen VS. ~ 250 classn. Ich denke, das sagt am meisten darüber, wie viel ein Nachschlagen brauchen würde. Wenn Sie nach !function_exists('') auf etwa 50-100 functionen in Ihrem Thema rufen … setzen Sie einfach einen Timer für einen und starten Sie dann etwas Mathe. Selbst wenn es nicht OOP ist, ist es eine gute Möglichkeit, Code zu erstellen

1) wiederverwendbar
2) wartbar
3) austauschbar
4) etwas schneller

Wenn Sie sich verschiedene im Web herumtreibende classn ansehen, die Ihnen helfen, Meta-Boxen, Widgets usw. schnell zu erstellen, dann ist es gut, einen Controller wie @toscho zu verwenden, da Sie einfach classn ein- und ausschließen und einfach ersetzen können einige Zeilen in der Steuerung, die Ihre classn behandelt.

Einige argumentieren, dass Verkapselung der einzige (oder zumindest primäre) Vorteil ist, den OOP bietet, und dass inheritance und Zustand irgendwo zwischen langweilig und böse sind:

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

Der Autor spricht mehr über die Verwendung von classn / Objekten als Strukturen als als Container für statische functionen, aber es ist interessant, einen völlig anderen Blick auf die Frage von jemandem zu lesen, der direkt außerhalb des OOP-Camps ist.

Ich könnte mein nächstes WordPress Plugin in Haskell schreiben.

Oh, die Diskussion! Ich muss auch zugeben, dass ich viel häufiger classn für die Verkapselung verwende. Die Idee ist hier, dass ich in meinen Plugins meine functionen in eine class einbinden kann und innerhalb dieser class sehr einfache, sinnvolle Methodennamen verwende, die selbst unter anderen Plugins, die ich schreibe, generisch sind. In diesem Fall sind classn ein Ersatz für Namespaces, die ich für Umgebungen mit 5.2.x vermeiden muss.

Während es einige wenige Fälle gibt, in denen OOP für die Modularität nützlich ist, bietet der einfache Vorgang des Wrapping Ihrer functionen auch den zusätzlichen Vorteil der pluginübergreifenden Erweiterbarkeit. Zum Beispiel habe ich kürzlich eine Berechnungslösung erweitert, die klassenbasiert ist. Da ich die Hauptklasse erweitern, zusätzlichen Code zu verschiedenen functionen (w / parent :: calls) hinzufügen oder sogar functionen ersetzen kann, ohne das erweiterte Plugin zu internalisieren.

Allas ist Class Wrapping jedoch meist nur ein Ersatz für Namespaces.

Was ist der Grund, sich über Code zu beschweren, den du nicht geschrieben hast?

Wenn Sie den Code nicht mögen, schreiben Sie Ihren eigenen!

Einfach. Problem getriggers.

Programmierer mögen es, Dinge auf ihre Art zu tun. Nehmen Sie also nicht an, dass Sie ihnen sagen können, wie man Code schreibt, welche Art von Whiskey zu trinken ist, welche Art von Zigarette zu rauchen oder welche Religion zu folgen. Sie werden nur solche Schmähungen debuggen und weitermachen, was sie wollen. 😉

Code ist keine Poesie. Code ist eine Variation des Sinatra-Songs “My Way” …