Usare le classi invece delle funzioni globali in Functions.php


11

In molti temi che ho visto (incluso TwentyEleven) e negli esempi che ho trovato online, quando si crea il functions.phpfile per un tema tutte le funzionalità sono dichiarate in un ambito globale. Per chiarire, ecco come appare un tipico file di funzioni:

function my_theme_do_foo() { // ... }

function my_theme_do_bar() { // ... }

add_action( 'foo_hook', 'my_theme_do_foo' );

Mi sembrerebbe che le cose potrebbero essere "incapsulate" un po 'meglio se si usasse una classe:

class MyTheme {
    function do_foo() { // ... }
    function do_bar() { // ... }
}

$my_theme = new MyTheme();

add_action( 'foo_hook', array( &$my_theme, 'do_foo' ) );

I vantaggi del secondo approccio (ai miei umili occhi):

  • Nomi di funzioni più brevi
  • Accesso alle variabili di istanza (il più grande vantaggio IMO)
  • Nessuna funzione globale

Gli svantaggi:

  • Il nome della classe potrebbe ancora causare conflitti
  • Non è così chiaro "personalizzare" con un tema figlio (dovrebbe estendere una classe genitore)
  • La maggior parte dei temi non ha funzionato in questo modo, quindi dovresti invertire la tendenza

Probabilmente sto trascurando alcune cose, ma mi chiedo perché non adottare l'approccio OOP? Mi sembra un po 'più "pulito", semmai. Forse mi sbaglio?

Sono abbastanza nuovo nello sviluppo del tema WordPress, quindi perdonami se questa è una conoscenza comune nella comunità WP :). Sto solo cercando di capire perché le cose sono come sono.


Puoi controllare i temi da Kovshenin - wordpress.org/extend/themes/profile/kovshenin usa l'approccio OOP in
Functions.php

Risposte:


9

L'uso di una classe per l'incapsulamento è un approccio molto comune da parte di numerosi sviluppatori per i plugin. Lo faccio e lo trovo più pulito. Ma per i plugin. I temi sono più procedurali per natura.

Non lo facciamo per i temi predefiniti di WordPress perché aumenta la barriera all'ingresso. Le funzioni sono abbastanza semplici. La rimozione di azioni legate alle classi può essere difficile (e potenzialmente buggy in circostanze specifiche).

Inoltre, è possibile collegare una serie di funzioni nei temi predefiniti. L'estensione di una classe e la sostituzione dei metodi è molto più complicata della semplice definizione della funzione. E mentre due diversi aspetti del codice possono sostituire funzioni diverse, non è possibile estendere dinamicamente le classi. Come hai sottolineato, la necessità di estendere una classe genitore è sicuramente uno svantaggio.

Ho considerato di rendere il codice delle opzioni del tema di Twenty Eleven una classe, ma non ci sono mai riuscito. Quel tipo di funzionalità separata simile a un plug-in sembra un buon candidato per l'incapsulamento.


Grazie per la risposta, Nacin. Non avevo pensato alla difficoltà di "sganciare" le azioni con le classi. Per quanto riguarda l'incapsulamento delle opzioni, abbiamo pensato la stessa cosa: github.com/jestro/struts
Andy Adams,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.