Usar clases en lugar de funciones globales en functions.php


11

En muchos temas que he visto (incluido TwentyEleven) y en los ejemplos que he encontrado en línea, al compilar el functions.phparchivo para un tema, toda la funcionalidad se declara en un ámbito global. Para aclarar, así es como se ve un archivo de funciones típico:

function my_theme_do_foo() { // ... }

function my_theme_do_bar() { // ... }

add_action( 'foo_hook', 'my_theme_do_foo' );

Me parece que las cosas podrían "encapsularse" un poco mejor si se usara una clase:

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

$my_theme = new MyTheme();

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

Las ventajas del segundo enfoque (en mis humildes ojos):

  • Nombres de funciones más cortos
  • Acceso a variables de instancia (la mayor ventaja de la OMI)
  • Sin funciones globales.

Las desventajas:

  • El nombre de clase aún podría causar conflictos
  • No es tan claro "personalizar" con un tema secundario (tendría que extender una clase principal)
  • La mayoría de los temas no lo han hecho de esta manera, por lo que estarías resistiendo la tendencia

Probablemente estoy pasando por alto algunas cosas, pero me pregunto ¿por qué no adoptar el enfoque OOP? Se siente un poco "más limpio" para mí, en todo caso. Quizás estoy equivocado?

Soy bastante nuevo en el desarrollo de temas de WordPress, así que perdóname si esto es de conocimiento común en la comunidad de WP :). Solo trato de aprender por qué las cosas son como son.


Puede consultar temas de Kovshenin: wordpress.org/extend/themes/profile/kovshenin , utiliza el enfoque OOP en functions.php
Mamaduka

Respuestas:


9

El uso de una clase para la encapsulación es un enfoque muy común por varios desarrolladores para complementos. Hago esto y lo encuentro más limpio. Pero para complementos. Los temas son más procesales por naturaleza.

No lo hacemos para los temas predeterminados de WordPress porque aumenta la barrera de entrada. Las funciones son bastante simples. Eliminar acciones vinculadas a clases puede ser difícil (y potencialmente defectuoso en circunstancias específicas).

Además, una serie de funciones en los temas predeterminados son conectables. Ampliar una clase y reemplazar los métodos es mucho más complicado que solo definir la función. Y aunque dos aspectos diferentes del código pueden reemplazar diferentes funciones, no puede extender dinámicamente las clases. Como señaló, la necesidad de extender una clase para padres es definitivamente una desventaja.

Pensé en convertir el código de opciones de tema de Twenty Eleven en una clase, pero nunca lo logré. Ese tipo de funcionalidad separada similar a un complemento parece ser un buen candidato para la encapsulación.


Gracias por la respuesta, Nacin. No había pensado en la dificultad de "desenganchar" acciones con las clases. Con respecto a la encapsulación de opciones, hemos estado pensando lo mismo: github.com/jestro/struts
Andy Adams
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.