Usando OOP en temas

36

Veo muchos complementos que utilizan codificación orientada a objetos cuando realmente no es necesario.

Pero lo que es aún peor es que los desarrolladores de temas están comenzando a hacer lo mismo. Los temas comerciales y los temas populares gratuitos como Suffusion, incluso mi tema favorito: Híbrido, guardan 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 usará dos o más instancias del mismo tema, al mismo tiempo.

Supongamos que los complementos hacen esto para 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?

themes php oop Pony de un solo truco
fuente
55
@ Amoeba ambiciosa: ¿Puede explicar por qué cree que usar clases para complementos para minimizar las colisiones en el espacio de nombres es ridículo? En cuanto a los temas, tal vez sería útil también si pudiera dar ejemplos de lo que considera que es un buen código en los temas y lo que considera innecesario. Discutir esto en abstracto no es probable que logre una idea para usted o para otros, especialmente para aquellos que no están familiarizados con lo que se refiere.
MikeSchinkel
1
Uso clases siempre que puedo personalmente, es mucho más fácil para mí mantener, actualizar y reutilizar. Dejando a un lado la preferencia personal, ¿qué buenas razones hay para usar una clase?
t31os
1
Extraño, acabo de perder mi comentario original (¿error de SE quizás?) Sin embargo, lo repetiré, ¿qué buenas razones hay para no usar una clase?
t31os
2
@ MikeSchinkel: puede hacerlo agregando un prefijo al nombre de la función. No creo que valga la sobrecarga de clase adicional solo para tener buenos nombres de funciones. De todos modos, tengo curiosidad sobre por qué los temas hacen esto, no tanto sobre los complementos
onetrickpony
44
@ Amoeba ambiciosa: ciertamente daré por hecho que tienes derecho a tu opinión, pero mi opinión es diferente. Creo que la claridad que las clases aportan al código al minimizar las funciones que flotan en el espacio de nombres global vale lo que creo que es una cantidad realmente inconmensurable de sobrecarga adicional, especialmente cuando se usa un IDE de nivel profesional como PhpStorm. Y las clases crean una unidad autónoma para que el desarrollador pueda saber qué código requiere un módulo. Y finalmente, después de evolucionar mi estilo de complemento de WordPress para usar clases, cualquier otro método me parece una codificación descuidada.
MikeSchinkel

Respuestas:

26

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

En el caso de Hybrid, solo usan una clase para nombrar sus funciones. Teniendo en cuenta que Hybrid es un marco de temas , 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 usaba una estructura de clase, los desarrolladores de temas secundarios tendrían que saber cuáles eran todas las llamadas a funciones existentes para poder evitar la reutilización de nombres. Y sí, podría simplemente prefijar todas sus funciones con una babosa única, pero eso hace que el código sea difícil de leer, difícil de mantener e inherentemente no reutilizable si desarrolla sistemas adicionales que quieran utilizar la misma funcionalidad.

Para responder tu pregunta

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

No, no utilizará dos o más instancias del mismo tema. Pero como dije, piense en la estructura de clases en este caso como espacios de nombres de las funciones, no creando una instancia de objeto tradicional. Agrupar todo en una clase e instanciarlo para llamar a los métodos ( myClass->method();) o llamar a los métodos directamente ( myClass::method();) es una forma muy limpia de espacios de nombres de manera legible y reutilizable.

Por supuesto, siempre podría usar algo como en su myClass_method();lugar, pero si desea reutilizar cualquiera de este código en otro tema, en un complemento o en un marco de trabajo adicional, debe volver 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 para el espacio de nombres (lo cual es ridículo), pero ¿cuál es la excusa del tema? ¿Me estoy perdiendo de algo?

En la mayoría de las situaciones, estoy de acuerdo contigo. Sin embargo, esa mayoría está disminuyendo rápidamente. Alojo varios sitios en una instalación de MultiSite que usan variaciones del mismo tema. En lugar de volver a crear el mismo tema una y otra vez con pequeñas diferencias, tengo una sola "clase" para el tema principal y todos los temas secundarios amplían 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 clases para el espacio de nombres de 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 clases para facilitar la extensibilidad por temas secundarios.

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

Si solo usa Hybrid en su sitio, hay poco que conocer como ventaja para usted como usuario final. Si está creando un tema secundario para Híbrido, existen ventajas de espacio de nombres y 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 usted es un desarrollador de temas que le gusta una característica específica de Hybrid pero no el tema completo, la ventaja radica en la reutilización de código rápida y eficiente en su proyecto no híbrido (suponiendo que también sea GPL).

EAMann
fuente
No estoy de acuerdo con la parte de "extensibilidad". Tiene el mismo nivel de control sobre el tema principal como lo haría si usara acciones y sus funciones típicas. ¿Por qué? Lo dijiste tú mismo, esto no es cierto OOP. Tampoco estoy de acuerdo con el espacio de nombres, es por eso que comencé esta pregunta en primer lugar: intente redefinir cualquier función de Hybrid en cualquier complemento y verá que las funciones colisionarán. ¿Por qué crees que todavía agregaron los prefijos? :) Usted simplemente no puede envolver todo el tema en una clase, simplemente no tiene ningún sentido ...
onetrickpony
No estoy diciendo que no uses OOP en temas, como algunas personas aquí podrían haber entendido, por el contrario (ver 2.8 widgets para, por ejemplo, caminantes, etc.), pero no así.
onetrickpony
1
Parece que tiene un problema con la implementación específica de Hybrid, no con la práctica de usar OOP en temas o incluso usar una clase para nombrar las funciones definidas en un tema. Estaba tratando de responder a sus preguntas más amplias sobre: ​​¿por qué hacer esto? y re: ¿cuáles son las ventajas de hacer esto? No voy a perder tiempo defendiendo lo que parece ser una implementación poco entusiasta o argumentando en contra de su evidente animosidad hacia la estructura de un marco de tema específico. En pocas palabras, si no le gusta la forma en que se construyó el híbrido, use otra cosa.
EAMann
1
en absoluto, me gusta híbrido (pero no la clase, por supuesto). Hybrid me inspiró para crear mi propio marco temático. Tome otro ejemplo, Suffusion, el mismo tipo de práctica. Una vez más, los espacios de nombres en este caso no funcionan con temas, todas las funciones dentro de la clase contenedora siempre entrarán en conflicto con los complementos, ya que los complementos se cargan con los temas "dentro" de WP.
onetrickpony
1
Lo suficientemente justo. Solo trate de tener en cuenta que la mayoría del trabajo de WP no es OOP para empezar (ya que WP no lo es), pero poner los métodos de tema en una clase para imitar cómo se hace en un complemento es al menos un paso a la derecha dirección ... incluso si es una clase medio concebida y mal implementada. Definitivamente estoy de acuerdo en que simplemente envolver todo en una clase y llamar a las cosas de manera procesal es un poco extraño (y no es útil desde el punto de vista de un desarrollador externo que intenta usar el sistema). Pero si se hace correctamente (y en Hybrid aparentemente no lo es), su código functions.phppuede ser muy poderoso.
EAMann
29

Velocidad

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

Ámbitos estrechos

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

Mantenimiento

Cada clase es un archivo. Si necesito actualizar el tema de un cliente, simplemente actualizo algunos archivos. Lo que ocurra dentro de las clases depende de mí siempre que ofrezco la misma API.

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

do_action( 'load_comment_class' );
comment_form();

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

Pruebe esto con un enfoque de procedimiento puro y se volverá loco. :)

Legibilidad

Es mucho más fácil releer y comprender su propio código algunos meses después si ha separado todo por su tarea.

Algunos ejemplos de jerarquías de clases útiles.

  • Meta_Box-> extendido por Shortdesc_Meta_Boxy Simple_Checkbox_Meta_Box-> extendido porSidebar_Switch
  • User_Profile_Addon-> ampliado por User_Profile_Checkbox(véase la pregunta 3255 )
  • Comment_Form -> extendido por {$theme_name}_Comment_Form
fuxia
fuente
1
¿Alguna oportunidad de obtener sus clases 'temáticas'? Quiero escribir el mío y me gustaría saber cómo lo haces.
Horttcore
1
No he decidido esto todavía. Tal vez estoy desarrollando un nuevo tema base junto con @bueltge el próximo año que usa algunas de estas clases. Muy probablemente no antes de marzo, me temo.
fuxia
55
Especialmente para sus casos, temas y marcos gratuitos, OOP es el camino a seguir. Otras personas tienen que trabajar con estos códigos. Los autores deben hacer que este proceso sea lo más fácil y flexible posible. Reemplazar una clase es más fácil que reemplazar 20 funciones, porque una clase bien escrita tiene una API claramente definida.
fuxia
2
No puedo decir nada sobre híbrido; Nunca lo he usado. Pero sí, un controlador que organiza todo detrás de las cortinas, ofrece buenos filtros e inserta algún patrón MVC en el desorden de tema habitual: es una buena cosa. No confíes en mi. Intentalo. :)
fuxia
3
Es hora, WordPress necesita un tema OOP para desarrolladores; Espero encontrar el tiempo para trabajar por nuestro objetivo. Este pequeño extracto aquí y los beneficios muestran las grandes posibilidades con oop para temas de clientes; Una forma rápida de realizar nuevos temas y también excelente para el mantenimiento.
bueltge
3

Otro punto a considerar: la 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 dice más sobre cuánto necesitaría una búsqueda. Si solicita !function_exists('')alrededor de 50-100 funciones en su tema ... simplemente configure un temporizador para una y luego comience a hacer algunas matemáticas. Incluso si no es OOP, es una buena manera de hacer código

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

Cuando echas un vistazo a diferentes clases que flotan en la web que te ayudan a hacer meta cuadros, widgets, etc. rápidamente, entonces es bueno usar un controlador como @toscho mencionado, porque puedes conectar y desconectar clases y simplemente reemplazar algunas líneas en el controlador que maneja tus clases.

emperador
fuente
2

Algunos argumentan que la encapsulación es el único (o al menos primario) beneficio que ofrece OOP, y que la herencia y el estado se encuentran entre aburridos y malvados:

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

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

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

Texas
fuente
1
Blog abierto solo para usuarios "invitados", desafortunadamente. Solo otro recordatorio de por qué nunca deberíamos publicar nuestra información en un servicio gratuito y, en cambio, deberíamos alojar nuestros propios blogs. Facebook es muy parecido a este respecto. Un enlace de recursos actualizado sería bueno. FWIW He visto el lado oscuro de OOP y nunca lo volveré a usar a menos que sea absolutamente necesario dentro del contexto, ya que las funciones de orden superior generalmente pueden ampliar la funcionalidad y ayudar a reducir la repetitiva y el mal uso de la classpalabra clave.
Josh Habdas
2

¡Oh, toda la discusión! Tengo que admitir también que uso clases para encapsular con mucha frecuencia. La idea es que en mis complementos, puedo ajustar mis funciones en una clase, y dentro de esa clase usar 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 OOP es útil para la modularidad, el simple acto de ajustar sus funciones también crea la ventaja adicional de la capacidad de ampliación de complementos cruzados. Por ejemplo, recientemente extendí una solución de facturación que estaba basada en la clase, y como tal podría extender la clase principal, agregar código adicional a varias funciones (w / parent :: calls) o incluso reemplazar funciones, todo sin internalizar el complemento extendido.

Sin embargo, en general, el ajuste de clase es solo un sustituto de espacios de nombres.

Jester831
fuente
-4

¿Qué sentido tiene 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 suponga que puede decirles cómo escribir código, qué tipo de whisky beber, qué marca de cigarrillos 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. Code es una variación de la canción de Sinatra "My Way" ...

marca
fuente
10
Esta pregunta no se queja del código, está pidiendo una explicación clara de por qué el código se escribiría de una manera particular. Gran parte del núcleo de WP es de procedimiento, con algunas características más nuevas que utilizan un enfoque OOP. Muchos complementos modernos también usan OOP para encapsular la funcionalidad. Pero la mayoría de los temas no. El OP preguntaba por qué se utilizaría un enfoque de pseudo-OOP y dio a Hybrid como ejemplo. No estás respondiendo la pregunta, estás despotricando.
EAMann