Utilizzo di OOP nei temi

36

Vedo molti plugin che fanno uso della codifica orientata agli oggetti quando non è davvero necessario.

Ma la cosa peggiore è che gli sviluppatori di temi stanno iniziando a fare la stessa cosa. Temi commerciali e temi popolari gratuiti come Suffusion, anche il mio tema preferito - Hybrid, inseriscono tutte le loro funzioni all'interno di una classe, istanziandolo una volta in Functions.php ed esegui le sue funzioni in modo procedurale :)

Wtf? Che senso ha fare questo? Ovviamente non userete due o più istanze dello stesso tema, contemporaneamente.

Supponiamo che i plugin lo facciano per lo spazio dei nomi (che è ridicolo), ma qual è la scusa del tema? Mi sto perdendo qualcosa?

Qual è il vantaggio di codificare un tema come questo?

themes php oop

— onetrickpony
fonte

5

@Ambitious Amoeba - Puoi spiegare perché credi che usare le classi per i plugin per minimizzare le collisioni dello spazio dei nomi sia ridicolo? Per quanto riguarda i temi, forse sarebbe utile anche se tu potessi fornire esempi di ciò che consideri un buon codice nei temi e di ciò che stai considerando non necessario. Discutere questo in astratto non è probabile che ottenga alcuna intuizione per te o per gli altri, specialmente gli altri che non hanno familiarità con ciò a cui ti riferisci.

— MikeSchinkel,

1

Uso le lezioni ovunque io sia personalmente, è molto più facile per me mantenere, aggiornare e riutilizzare. Preferenze personali a parte, quali buoni motivi ci sono per usare una classe?

— t31os,

1

Strano, ho appena perso il mio commento originale (forse bug SE?) .. Lo ripeterò, quali buoni motivi ci sono per non usare una classe?

— t31os,

2

@MikeSchinkel: puoi farlo aggiungendo un prefisso al nome della funzione. Non penso che valga la pena sovraccaricare la classe extra solo per avere dei bei nomi di funzioni. Ad ogni modo, sono curioso di sapere perché i temi fanno questo, non tanto per i plugin

— onetrickpony,

4

@Ambiziosa Amoeba - Certamente darò che hai diritto alla tua opinione, ma la mia opinione è diversa. Credo che la chiarezza che le classi apportano al codice riducendo al minimo le funzioni fluttuanti nello spazio dei nomi globale valga ciò che ritengo essere una quantità effettivamente incommensurabile di sovraccarico aggiuntivo, specialmente quando si utilizza un IDE di livello professionale come PhpStorm. E le classi creano un'unità autonoma in modo che lo sviluppatore possa sapere quale codice richiede un modulo. E infine, dopo aver evoluto il mio stile di plugin WordPress per usare le classi, qualsiasi altro metodo mi sembra semplicemente un codice sciatto.

— MikeSchinkel,

26

Posso capire la tua confusione in base all'esempio che hai fornito. Questo è davvero un modo scarso di usare una classe ... e solo perché viene usata una classe, non rende un sistema OOP.

Nel caso di Hybrid, stanno semplicemente usando una classe per lo spazio dei nomi delle loro funzioni. Considerando che Hybrid è un framework di temi , questo viene fatto in modo che i temi secondari possano riutilizzare i nomi delle funzioni senza che lo sviluppatore debba preoccuparsi della collisione dei nomi. In molti casi, un framework di temi (tema genitore) è così complesso, molti sviluppatori di temi per bambini non capiranno mai esattamente cosa succede sotto il cofano.

Se Hybrid non utilizzava una struttura di classe, gli sviluppatori di temi figlio avrebbero bisogno di sapere quali erano tutte le chiamate di funzione esistenti per evitare di riutilizzare i nomi. E sì, potresti semplicemente aggiungere un prefisso a tutte le tue funzioni con una lumaca unica, ma ciò rende il codice difficile da leggere, difficile da mantenere e intrinsecamente non riutilizzabile se dovessi sviluppare altri sistemi che desiderano utilizzare la stessa funzionalità.

Per rispondere alle tue domande

Wtf? Che senso ha fare questo? Ovviamente non userete due o più istanze dello stesso tema, contemporaneamente.

No, non utilizzerai due o più istanze dello stesso tema. Ma come ho detto, in questo caso la struttura delle classi deve essere considerata come spaziatura dei nomi delle funzioni, non creazione di un'istanza di oggetto tradizionale. Raggruppare tutto insieme in una classe e istanziarlo per chiamare metodi ( myClass->method();) o chiamare metodi direttamente ( myClass::method();) è un modo molto pulito di spaziare le cose in modo leggibile e riutilizzabile.

Ovviamente potresti sempre usare qualcosa di simile myClass_method();, ma se vuoi riutilizzare uno di questi codici in un altro tema, in un plug-in o in un altro quadro devi tornare indietro e cambiare tutti i tuoi prefissi. Mantenere tutto in una classe è più pulito e ti consente di riqualificare e ridistribuire molto più rapidamente.

Supponiamo che i plugin lo facciano per lo spazio dei nomi (che è ridicolo), ma qual è la scusa del tema? Mi sto perdendo qualcosa?

Nella maggior parte dei casi sono d'accordo con te. Tuttavia, quella maggioranza sta rapidamente calando. Ospito diversi siti su un'installazione MultiSite che utilizzano varianti dello stesso tema. Invece di ricreare lo stesso tema più e più volte con differenze minori, ho una sola "classe" per il tema principale e tutti i temi figlio estendono quella classe. Ciò mi consente di definire funzionalità personalizzate per ciascun sito pur mantenendo un senso generale di uniformità su tutta la rete.

Da un lato, gli sviluppatori di temi possono scegliere un approccio di classe basato sullo spazio dei nomi per le loro funzionalità (il che non è ridicolo se lavori in un ambiente in cui riutilizzi ripetutamente blocchi dello stesso codice). D'altro canto, gli sviluppatori di temi possono scegliere un approccio di classe per una facile estensibilità con temi figlio.

Qual è il vantaggio di codificare un tema come questo?

Se utilizzi solo Hybrid sul tuo sito, c'è poco da sapere per te come utente finale. Se stai creando un tema figlio per Hybrid, ci sono vantaggi di spaziatura dei nomi ed estensibilità. Se lavori per ThemeHybrid , il vantaggio sta nel riutilizzo del codice rapido ed efficiente in tutti gli altri tuoi progetti (Prototype, Leviathan, ecc.).

E se sei uno sviluppatore di temi a cui piace una funzionalità specifica di Hybrid ma non l'intero tema, il vantaggio sta nel riutilizzo del codice rapido ed efficiente nel tuo progetto non Hybrid (supponendo che sia anche GPL).

— EAMann
fonte

Non sono d'accordo con la parte "estensibilità". Hai lo stesso livello di controllo sul tema principale come se avessi usato le azioni e le tue funzioni tipiche. Perché? L'hai detto tu stesso, questo non è vero OOP. Neanche io sono d'accordo con lo spazio dei nomi - questo è il motivo per cui ho iniziato questa domanda in primo luogo - Prova a ridefinire qualsiasi funzione di Hybrid in qualsiasi plugin e vedrai che le funzioni si scontreranno. Perché pensi che abbiano ancora aggiunto i prefissi? :) Non puoi semplicemente avvolgere l'intero tema in una classe, semplicemente non ha alcun senso ...

— onetrickpony

Non sto dicendo di non usare OOP nei temi, come alcune persone qui potrebbero aver capito, al contrario (vedi 2.8 widget per es., Walker ecc.), Ma non così.

— onetrickpony,

1

Sembra che tu abbia un problema con l'implementazione specifica di Hybrid, non con la pratica di usare OOP nei temi o addirittura usare una classe per lo spazio dei nomi delle funzioni definite in un tema. Stavo cercando di rispondere alle tue domande più ampie riguardo a: perché farlo? e ri: quali sono i vantaggi di farlo? Non passerò il tempo a difendere quella che sembra un'implementazione spensierata o a discutere contro la tua ovvia animosità verso la struttura di un tema specifico. In conclusione, se non ti piace il modo in cui è stato creato Hybrid, usa qualcos'altro.

— EAMann,

1

per niente, mi piace l'ibrido (ma non la cosa di classe ovviamente). L'ibrido mi ha ispirato a creare la mia struttura tematica. Prendi un altro esempio, Suffusion, stesso tipo di pratica. Ancora una volta, gli spazi dei nomi in questo caso non funzionano con i temi, tutte le funzioni all'interno della classe wrapper saranno sempre in conflitto con i plugin, poiché i plugin sono caricati dai temi "all'interno" di WP.

— onetrickpony,

1

Giusto. Cerca di tenere a mente che la maggior parte del lavoro di WP non è OOP per cominciare (dal momento che WP non lo è), ma mettere i metodi del tema in una classe per imitare il modo in cui è fatto in un plug-in è almeno un passo a destra direzione ... anche se è una classe concepita per metà e mal implementata. Sono assolutamente d'accordo sul fatto che semplicemente racchiudere tutto in una classe e chiamare le cose proceduralmente sia un po 'strano (e non utile dal POV di uno sviluppatore di terze parti che cerca di utilizzare il sistema). Ma se fatto correttamente (e in Hybrid apparentemente non lo è), il class-ifying del tuo codice functions.phppuò essere molto potente.

— EAMann,

29

Velocità

Il mio tema di base attuale ha 13 lezioni. Quando creo un nuovo tema, utilizzo queste classi così come sono o le estendo. Tale sistema rende il processo di costruzione di un nuovo tema molto, molto veloce.

Ambiti stretti

Raramente ho bisogno di variabili globali, perché tutto ciò che il mio codice deve sapere è nascosto nei membri della classe. Quindi sono in grado di condividere una variabile tra due filtri o azioni molto diversi senza il rischio di collisione con plugin scritti male.

Manutenzione

Ogni classe è un file. Se devo aggiornare il tema di un client, aggiorno solo alcuni file. Qualunque cosa accada all'interno delle lezioni dipende da me, purché offra la stessa API.

Un esempio: sopra la comment_form();chiamata, utilizzo una semplice azione:

do_action( 'load_comment_class' );
comment_form();

Quale classe di commento verrà caricata decide il mio controller. Cosa succede esattamente all'interno della classe di commento decide la singola classe.

Prova questo con un approccio procedurale puro e stai impazzendo. :)

leggibilità

È molto più semplice rileggere e comprendere il proprio codice alcuni mesi dopo se si è separato tutto dal suo compito.

Alcuni esempi per utili gerarchie di classi

Meta_Box-> esteso di Shortdesc_Meta_Boxe Simple_Checkbox_Meta_Box-> esteso diSidebar_Switch
User_Profile_Addon-> esteso di User_Profile_Checkbox(vedi domanda 3255 )
Comment_Form -> esteso di {$theme_name}_Comment_Form

— fuxia
fonte

1

Qualche possibilità di ottenere le tue lezioni a tema? Voglio scrivere il mio e mi piacerebbe sapere come lo fai.

— Horttcore,

1

Non l'ho ancora deciso. Forse sto realizzando un nuovo tema di base insieme a @bueltge l'anno prossimo che utilizza alcune di queste classi. Molto probabilmente non prima di marzo, temo.

— fuxia

5

Soprattutto per i tuoi casi, temi e framework gratuiti, OOP è la strada da percorrere. Altre persone devono lavorare con questi codici. Gli autori dovrebbero rendere questo processo il più semplice e flessibile possibile. Sostituire una classe è più semplice che sostituire 20 funzioni, perché una classe ben scritta ha un'API chiaramente definita.

— fuxia

2

Non posso dire nulla su Hybrid; Non l'ho mai usato. Ma sì, un controller che organizza tutto dietro le tende, offre buoni filtri e inserisce alcuni schemi MVC nel solito pasticcio di temi: è una buona cosa. Non fidarti di me. Provalo. :)

— fuxia

3

È tempo, WordPress ha bisogno di un tema OOP per gli sviluppatori; spero di trovare il tempo di lavorare per il nostro obiettivo. Questo piccolo estratto qui e i vantaggi mostrano le grandi possibilità con oop per i temi dei clienti; un modo rapido per realizzare nuovi temi e anche per la manutenzione.

— fusione

3

Un altro punto da considerare: la velocità.

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

Dopo una breve occhiata / stampa ho trovato ~ 1.700 funzioni interne e ~ 1.400 funzioni utente = ~ 3.100 / 3.200 funzioni VS. ~ 250 classi. Immagino che questo dica di più su quanto sarebbe necessario uno sguardo. Se !function_exists('')richiedi circa 50-100 funzioni nel tuo tema ... basta impostare un timer per uno e quindi iniziare a fare un po 'di matematica. Anche se non è OOP è un buon modo per creare codice

1) riutilizzabile
2) mantenibile
3) scambiabile
4) leggermente più veloce

Quando dai un'occhiata a diverse classi che fluttuano nel web che ti aiutano a fare meta box, widget, ecc. Velocemente, allora è bene usare un controller come @toscho menzionato, perché puoi semplicemente inserire e uscire le classi e semplicemente sostituire alcune righe nel controller che gestisce le tue classi.

— Kaiser
fonte

2

Alcuni sostengono che l'incapsulamento sia l'unico (o almeno primario) vantaggio offerto da OOP e che l'eredità e lo stato siano a metà strada tra noioso e malvagio:

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

L'autore sta parlando di più sull'uso di classi / oggetti come strutture piuttosto che come contenitori per funzioni statiche, ma è interessante leggere un punto di vista completamente diverso sulla domanda, da qualcuno che è esattamente fuori dal campo OOP.

Potrei scrivere il mio prossimo plugin WordPress in Haskell.

— Tex
fonte

1

Blog aperto solo agli utenti "invitati", purtroppo. Solo un altro promemoria sul perché non dovremmo mai pubblicare le nostre informazioni su un servizio gratuito e, invece, dovremmo ospitare i nostri blog. Facebook è molto simile a questo riguardo. Un collegamento di risorse aggiornato sarebbe carino. FWIW Ho visto il lato oscuro di OOP e non lo userò mai più a meno che non sia assolutamente necessario nel contesto, poiché le funzioni di ordine superiore in genere possono estendere la funzionalità e aiutare a ridurre la targhetta e l'uso improprio della classparola chiave.

— Josh Habdas,

2

Oh, piuttosto la discussione! Devo anche ammettere che uso le classi per l'incapsulamento molto più spesso. L'idea è che nei miei plugin posso racchiudere le mie funzioni in una classe e all'interno di quella classe uso nomi di metodi molto semplici e significativi che sono generici anche tra gli altri plugin che scrivo. In quel caso, le classi sostituiscono gli spazi dei nomi, che sono costretto a evitare per gli ambienti 5.2.x.

Mentre ci sono pochi casi in cui OOP è utile per la modularità, il semplice atto di racchiudere le tue funzioni crea anche il vantaggio aggiuntivo di estensibilità cross-plug-in. Ad esempio, di recente ho esteso una soluzione di fatturazione basata sulla classe e, essendo tale, potrei estendere la classe principale, aggiungere codice aggiuntivo a varie funzioni (w / parent :: Calls) o persino sostituire funzioni, il tutto senza internalizzare il plugin esteso.

Tuttavia, il wrapping di classe per la maggior parte è solo un sostituto per gli spazi dei nomi.

— Jester831
fonte

-4

Qual è il punto di lamentarsi del codice che non hai scritto?

Se non ti piace il codice, scrivi il tuo!

Semplice. Problema risolto.

Ai programmatori piace fare le cose a modo loro. Quindi non dare per scontato che puoi dire loro come scrivere il codice, che tipo di whisky da bere, quale marca di sigaretta da fumare o quale religione seguire. Eseguiranno semplicemente il debug di tale diatriba e continueranno a fare ciò che vogliono. ;-)

Il codice non è poesia. Il codice è una variante della canzone Sinatra "My Way" ...

— marchio
fonte

10

Questa domanda non si lamenta del codice, ma richiede una chiara spiegazione del perché il codice dovrebbe essere scritto in un modo particolare. Gran parte del core di WP è procedurale, con alcune nuove funzionalità che utilizzano un approccio OOP. Molti plug-in moderni usano anche OOP per incapsulare funzionalità. Ma la maggior parte dei temi no. L'OP stava chiedendo perché sarebbe stato usato un approccio pseudo-OOP e ha fornito Hybrid come esempio. Non stai rispondendo alla domanda, stai rantolando.

— EAMann,