Usando OOP en temas

35

Veo muchos complementos que hacen uso de la codificación orientada a objetos cuando realmente no es necesario.

Pero lo que es peor es que los desarrolladores de temas están empezando a hacer lo mismo. Los temas comerciales y los temas populares gratuitos como Suffusion, incluso mi tema favorito - Híbrido, completan todas sus funciones dentro de una clase, lo instancian una vez en functions.php y ejecutan sus funciones de manera procesal :)

Wtf? ¿Cuál es el punto de hacer esto? Obviamente, no utilizarás dos o más instancias del mismo tema al mismo tiempo.

Supongamos que los complementos hacen esto por el espacio de nombres (lo cual es ridículo), pero ¿cuál es la excusa del tema? ¿Me estoy perdiendo de algo?

¿Cuál es la ventaja de codificar un tema como este?

    
pregunta onetrickpony 22.12.2010 - 11:36

6 respuestas

26

Puedo entender su confusión según el ejemplo que proporcionó. Esa es realmente una mala manera de usar una clase ... y solo porque se use una clase, no hace un sistema OOP.

En el caso de Hybrid, solo están usando una clase para el espacio de nombres de sus funciones. Teniendo en cuenta que Hybrid es un tema framework , esto se hace para que los temas secundarios puedan reutilizar nombres de funciones sin que el desarrollador tenga que preocuparse por la colisión de nombres. En muchos casos, un marco temático (tema principal) es tan complejo que muchos desarrolladores de temas secundarios nunca entenderán exactamente lo que sucede debajo del capó.

Si Hybrid no usara una estructura de clase, los desarrolladores de temas secundarios necesitarían saber cuáles eran todas las llamadas a funciones existentes para evitar el reuso de los nombres. Y sí, usted podría prefijar todas sus funciones con un slug único, pero eso hace que el código sea difícil de leer, difícil de mantener e intrínsecamente no reutilizable si desarrolla otros sistemas que deseen utilizar la misma funcionalidad.

Para responder a tus preguntas

  

Wtf? ¿Cuál es el punto de hacer esto? Obviamente, no utilizarás dos o más instancias del mismo tema al mismo tiempo.

No, no usarás dos o más instancias del mismo tema. Pero como dije, piense en la estructura de clase en este caso como namespacing las funciones, no creando una instancia de objeto tradicional. Agrupar todo en una clase y crear una instancia de los métodos de llamada ( myClass->method(); ) o de los métodos de llamada directamente ( myClass::method(); ) es una forma muy clara de hacer espacios de nombres de forma legible y reutilizable.

Por supuesto, siempre puede usar algo como myClass_method(); en su lugar, pero si desea reutilizar algo de este código en otro tema, en un complemento o en otro marco, debe volver atrás y cambiar. todos sus prefijos Mantener todo en una clase es más limpio y le permite volver a desarrollar y volver a implementar mucho más rápidamente.

  

Supongamos que los complementos hacen esto por el espacio de nombres (lo cual es ridículo), pero ¿cuál es la excusa del tema? ¿Me estoy perdiendo algo?

En la mayoría de las situaciones estaría de acuerdo contigo. Sin embargo, esa mayoría está disminuyendo rápidamente. Alojé varios sitios en una instalación de MultiSite que usa variaciones del mismo tema. En lugar de volver a crear el mismo tema una y otra vez con pequeñas diferencias, tengo una única "clase" para el tema principal y todos los temas secundarios extienden esa clase. Esto me permite definir una funcionalidad personalizada para cada sitio mientras mantengo un sentido general de uniformidad en toda la red.

Por un lado, los desarrolladores de temas pueden elegir un enfoque basado en clase para el espacio de nombres en su funcionalidad (lo cual no es ridículo si trabaja en un entorno donde reutiliza fragmentos del mismo código una y otra vez). Por otro lado, los desarrolladores de temas pueden elegir un enfoque basado en clase para una fácil extensibilidad por temas secundarios.

  

¿Cuál es la ventaja de codificar un tema como este?

Si solo está utilizando Hybrid en su sitio, hay poca ventaja para usted como usuario final. Si está creando un tema secundario para Hybrid, hay ventajas en el espacio de nombres y la extensibilidad. Si trabaja para ThemeHybrid , la ventaja radica en la reutilización de código rápida y eficiente en sus otros proyectos (Prototype, Leviathan, etc.).

Y si eres un desarrollador de temas a quien le gusta una característica específica de Hybrid pero no todo el tema, la ventaja radica en la reutilización de código rápida y eficiente en tu proyecto no híbrido (asumiendo que también es GPL).

    
respondido por el EAMann 22.12.2010 - 16:58
29

Velocidad

Mi tema base actual tiene 13 clases. Cuando construyo un tema nuevo, uso estas clases como son o las extiendo. Ese sistema hace que el proceso de creación de un nuevo tema sea muy, muy rápido.

Ámbitos ajustados

Rara vez necesito variables globales, porque todo lo que mi código debe saber está oculto en los miembros de la clase. Así que puedo compartir una variable entre dos filtros o acciones muy diferentes sin el riesgo de colisión con complementos mal escritos.

Mantenimiento

Cada clase es un archivo. Si necesito actualizar el tema de un cliente, solo actualizo algunos archivos. Lo que suceda dentro de las clases depende de mí siempre y cuando ofrezca la misma API.

Un ejemplo: arriba de la llamada comment_form(); , uso una acción simple:

do_action( 'load_comment_class' );
comment_form();

La clase de comentarios que se cargará decide mi controlador. Lo que sucede exactamente dentro de la clase de comentarios decide la clase individual.

Intente esto con un enfoque de procedimiento puro y se está volviendo loco. :)

Legibilidad

Es mucho más fácil volver a leer y entender su propio código algunos meses más tarde si ha separado todo por su tarea.

Algunos ejemplos de jerarquías de clases útiles

  • Meta_Box - > extendido por Shortdesc_Meta_Box y Simple_Checkbox_Meta_Box - > extendido por Sidebar_Switch
  • User_Profile_Addon - > extendido por User_Profile_Checkbox (consulte pregunta 3255 )
  • Comment_Form - > extendido por {$theme_name}_Comment_Form
respondido por el fuxia 22.12.2010 - 12:27
3

Otro punto a considerar: Velocidad.

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

Después de un breve vistazo / impresión encontré ~ 1.700 funciones internas y ~ 1.400 funciones de usuario = ~ 3.100 / 3.200 funciones VS. ~ 250 Clases. Supongo que esto es lo que más dice acerca de cuánto necesitaría una búsqueda. Si llama a !function_exists('') en aproximadamente 50-100 funciones en su tema ... simplemente configure un temporizador para una y luego comience a hacer algunos cálculos matemáticos. Incluso si no es OOP, es una buena manera de hacer código

1) reutilizable
2) mantenible
3) intercambiable
4) poco más rápido

Cuando observas diferentes clases flotando en la web que te ayudan a hacer meta box, widgets, etc. rápidamente, entonces es bueno usar un controlador como @toscho mencionado, porque puedes conectar clases y entrar. y simplemente reemplace algunas líneas en el controlador que maneja sus clases.

    
respondido por el kaiser 03.03.2011 - 21:55
2

Algunos argumentan que la encapsulación es el único beneficio (o al menos primario) que ofrece la OOP, y que la herencia y el estado están en algún lugar entre aburrido y malvado:

enlace

El autor está hablando más sobre el uso de clases / objetos como estructuras que como contenedores para funciones estáticas, pero es interesante leer una versión completamente diferente de la pregunta, de alguien que se encuentra directamente fuera del campamento OOP.

Puedo escribir mi próximo complemento de WordPress en Haskell.

    
respondido por el Tex 07.04.2011 - 15:23
2

¡Oh, la discusión! También debo admitir que uso las clases para la encapsulación con mucha más frecuencia que no. La idea es que aquí, en mis complementos, puedo envolver mis funciones en una clase, y dentro de esa clase utilizo nombres de métodos muy simples y significativos que son genéricos incluso entre otros complementos que escribo. En ese caso, las clases son un sustituto de los espacios de nombres, que me veo obligado a evitar para los entornos 5.2.x.

Si bien hay pocos casos en que la POO es útil para la modularidad, el simple hecho de envolver tus funciones también crea la ventaja añadida de la capacidad de extensión de complemento cruzado. Por ejemplo, recientemente extendí una solución de facturación basada en clase, y como tal, podría extender la clase principal, agregar código extra a varias funciones (w / parent :: calls) o incluso reemplazar funciones, todo sin internalizar el complemento extendido.

Allas, sin embargo, el ajuste de clase en su mayor parte es solo un sustituto de los espacios de nombres.

    
respondido por el Jester831 26.04.2011 - 03:37
-3

¿Cuál es el motivo de quejarse del código que no escribió?

Si no te gusta el código, ¡escribe el tuyo!

Simple. Problema resuelto.

A los programadores les gusta hacer cosas a su manera. Así que no supongas que puedes decirles cómo escribir código, qué tipo de whisky beber, qué marca de cigarrillo fumar o qué religión seguir. Simplemente depurarán esa diatriba y seguirán haciendo lo que quieran. ;-)

El código no es poesía. El código es una variación de la canción "My Way" de Sinatra ...

    
respondido por el Mark 23.12.2010 - 05:44

Lea otras preguntas en las etiquetas