Verwendung von OOP in Themen

Ich sehe viele Plugins, die objektorientierte Codierung verwenden, wenn dies nicht wirklich notwendig ist.

Was aber noch schlimmer ist, ist, dass Theme-Entwickler beginnen, das Gleiche zu tun. Kommerzielle Themen und kostenlose beliebte Themen wie Suffusion, sogar mein Lieblingsthema - Hybrid, stopfen alle ihre Funktionen in eine Klasse, instanziieren sie einmal in functions.php und führen ihre Funktionen prozedural aus :)

Wtf? Was bringt das? Offensichtlich werden Sie nicht zwei oder mehr Instanzen desselben Themas gleichzeitig verwenden.

Nehmen wir an, dass die Plugins dies für den Namespace tun (was lächerlich ist), aber was ist die thematische Entschuldigung? Vermisse ich etwas?

Was ist der Vorteil eines solchen Themas?

Ich kann Ihre Verwirrung anhand des von Ihnen angegebenen Beispiels verstehen. Das ist wirklich ein schlechter Weg, eine Klasse zu benutzen ... und nur weil eine Klasse benutzt wird, macht das kein System-OOP.

Im Fall von Hybrid verwenden sie lediglich eine Klasse, um ihren Funktionen einen Namensraum zu geben. Da Hybrid ein Design- Framework ist, können untergeordnete Designs Funktionsnamen wiederverwenden, ohne dass sich der Entwickler um Namenskollisionen sorgen muss. In vielen Fällen ist ein Themen-Framework (übergeordnetes Thema) so komplex, dass viele Entwickler untergeordneter Themen niemals genau verstehen, was unter der Haube vor sich geht.

Wenn Hybrid keine Klassenstruktur verwenden würde, müssten Entwickler von untergeordneten Designs wissen, wie alle vorhandenen Funktionsaufrufe lauten, damit sie die Wiederverwendung von Namen vermeiden können. Und ja, Sie könnten allen Funktionen einen eindeutigen Slug voranstellen, aber das macht den Code schwer lesbar, schwer zu warten und von Natur aus nicht wiederverwendbar, wenn Sie weitere Systeme entwickeln, die dieselbe Funktionalität nutzen möchten.

Um Ihre Fragen zu beantworten

Wtf? Was bringt das? Offensichtlich werden Sie nicht zwei oder mehr Instanzen desselben Themas gleichzeitig verwenden.

Nein, Sie werden nicht zwei oder mehr Instanzen desselben Themas verwenden. Aber wie gesagt, stellen Sie sich die Klassenstruktur in diesem Fall als Namensraum für die Funktionen vor und nicht als Erzeugung einer traditionellen Objektinstanz. Wenn Sie alles in einer Klasse zusammenfassen und entweder zum Aufrufen von Methoden ( myClass->method();) oder zum direkten Aufrufen von Methoden ( myClass::method();) instanziieren, können Sie Namespace-Dinge auf lesbare und wiederverwendbare Weise erstellen.

Natürlich können Sie myClass_method();stattdessen auch so etwas verwenden, 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. Es ist sauberer, alles in einer Klasse zu halten, und Sie können es viel schneller neu entwickeln und bereitstellen.

Nehmen wir an, dass die Plugins dies für den Namespace tun (was lächerlich ist), aber was ist die thematische Entschuldigung? Vermisse ich etwas?

In den meisten Situationen stimme ich Ihnen zu. Diese Mehrheit lässt jedoch schnell nach. Ich hoste mehrere Sites in einer MultiSite-Installation, die Variationen desselben Themas verwenden. Anstatt dasselbe Thema mit geringfügigen Unterschieden immer wieder neu zu erstellen, habe ich eine einzige "Klasse" für das übergeordnete Thema, und alle untergeordneten Themen erweitern diese Klasse. Auf diese Weise kann ich benutzerdefinierte Funktionen für jeden Standort definieren und gleichzeitig ein allgemeines Gefühl der Einheitlichkeit im gesamten Netzwerk aufrechterhalten.

Einerseits können Theme-Entwickler einen klassenbasierten Ansatz wählen, um ihre Funktionalität als Namensraum zu definieren (was nicht lächerlich ist, wenn Sie in einer Umgebung arbeiten, in der Sie immer wieder Teile desselben Codes wiederverwenden). Andererseits können Theme-Entwickler einen klassenbasierten Ansatz wählen, um die Erweiterbarkeit durch untergeordnete Themes zu vereinfachen.

Was ist der Vorteil eines solchen Themas?

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

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

Geschwindigkeit

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

Enge Bereiche

Ich benötige selten globale Variablen, da alles, was mein Code wissen muss, in Klassenmitgliedern verborgen ist. So kann ich eine Variable zwischen zwei sehr unterschiedlichen Filtern oder Aktionen teilen, ohne die Gefahr einer Kollision mit schlecht geschriebenen Plugins.

Instandhaltung

Jede Klasse ist eine Datei. Wenn ich das Thema eines Kunden aktualisieren muss, aktualisiere ich nur einige Dateien. Was auch immer in den Klassen passiert, liegt bei mir, solange ich die gleiche API anbiete.

Ein Beispiel: Über dem comment_form();Aufruf verwende ich 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 jeweilige Klasse.

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 noch einmal zu lesen und zu verstehen, wenn Sie alles nach seiner Aufgabe getrennt haben.

Einige Beispiele für nützliche Klassenhierarchien

• Meta_Box-> verlängert um Shortdesc_Meta_Boxund Simple_Checkbox_Meta_Box-> verlängert umSidebar_Switch
• User_Profile_Addon-> erweitert um User_Profile_Checkbox(siehe Frage 3255 )
• Comment_Form -> erweitert um {$theme_name}_Comment_Form

Ein weiterer zu berücksichtigender Punkt: Geschwindigkeit.

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

Nach einem kurzen Blick / Ausdruck fand ich ~ 1.700 interne Funktionen und ~ 1.400 Benutzerfunktionen = ~ 3.100 / 3.200 Funktionen VS. ~ 250 Klassen. Ich denke, das sagt am meisten darüber aus, wie viel ein Nachschlagen benötigen würde. Wenn Sie !function_exists('')ungefähr 50-100 Funktionen in Ihrem Thema benötigen, stellen Sie einfach einen Timer für eine ein und beginnen Sie dann, etwas zu rechnen. Auch 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 Klassen ansehen, die im Web herumschwirren und Ihnen dabei helfen, Meta-Boxen, Widgets usw. schnell zu erledigen, ist es gut, einen Controller wie @toscho zu verwenden, da Sie Klassen einfach ein- und ausstecken und ersetzen können Einige Zeilen im Controller, die Ihre Klassen behandeln.

Einige argumentieren, dass die Kapselung der einzige (oder zumindest primäre) Vorteil ist, den OOP bietet, und dass Vererbung und Staat irgendwo zwischen langweilig und böse liegen:

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

Der Autor spricht mehr über die Verwendung von Klassen / Objekten als Strukturen als Container für statische Funktionen, aber es ist interessant, eine ganz andere Sichtweise auf die Frage zu lesen als auf jemanden, der sich direkt außerhalb des OOP-Lagers befindet.

Ich kann mein nächstes WordPress-Plugin in Haskell schreiben.

Ach so die Diskussion! Ich muss auch zugeben, dass ich Klassen weitaus häufiger zum Einkapseln benutze als nicht. Die Idee dabei ist, dass ich in meinen Plugins meine Funktionen in eine Klasse einbinden kann und innerhalb dieser Klasse sehr einfache, aussagekräftige Methodennamen verwende, die selbst unter anderen von mir geschriebenen Plugins generisch sind. In diesem Fall sind Klassen ein Ersatz für Namespaces, die ich für 5.2.x-Umgebungen vermeiden muss.

Es gibt zwar nur wenige Fälle, in denen OOP für die Modularität nützlich ist, aber der einfache Vorgang, Ihre Funktionen zu verpacken, schafft auch den zusätzlichen Vorteil der Plug-in-Erweiterbarkeit. Ich habe zum Beispiel kürzlich eine klassenbasierte Abrechnungslösung erweitert, mit der ich die Hauptklasse erweitern, verschiedenen Funktionen (mit parent :: -Aufrufen) zusätzlichen Code hinzufügen oder sogar Funktionen ersetzen kann, ohne das erweiterte Plugin zu internalisieren.

Allerdings ist der Klassenumbruch zum größten Teil nur ein Ersatz für Namespaces.

Was nützt es, sich über Code zu beschweren, den Sie nicht geschrieben haben?

Wenn Ihnen der Code nicht gefällt, schreiben Sie Ihren eigenen!

Einfach. Problem gelöst.

Programmierer mögen es, Dinge auf ihre Weise zu erledigen. Gehen Sie also nicht davon aus, dass Sie ihnen sagen können, wie sie Code schreiben sollen, welche Art von Whisky sie trinken sollen, welche Zigarettenmarke sie rauchen sollen oder welcher Religion sie folgen sollen. Sie debuggen einfach solche Fehler und machen weiter, was sie wollen. ;-)

Code ist keine Poesie. Code ist eine Variation des Sinatra-Songs "My Way" ...