¿Cuál es el patrón de diseño formal detrás del “monkeyparching”?

Question

Pregunta central de CS aquí:de los patrones de diseño enumerados en Gamma, etc., ¿cuáles (si los hay) cubren el parcheo de monos?Además, ¿para qué clase de problemas es apropiado el parcheo de monos vs.subclasificación?Parchar errores en las clases principales de la biblioteca es una de ellas, ¿hay otras?Escucho mucha confusión sobre el parcheo de monos en stackoverflow, la mayoría de ustedes parecen tener grandes dudas al respecto, pero como programador me gusta mucho la capacidad de encapsular partes genéricas de funcionalidad e incluirlas en mis modelos de objetos en rieles.

Tomemos como ejemplo thinkbot-paperclip, ¿por qué querría alguna vez crear una subclase de eso en comparación con el enfoque de parche de mono que existe hoy?

Gracias, -eter

Answer 1

No creo que el parche de mono sea un patrón de diseño: la extensión de clase principal es una característica del lenguaje que parecen ignorar.

Respecto al resto, eche un vistazo a las opiniones de Jeff Atwood sobre este artículo en su blog.

En su opinión (y en la mía), el mayor problema con el parche de mono es que puede dificultar mucho la depuración si modifica los métodos existentes: los humanos no podemos realizar un seguimiento de todos los "pequeños fragmentos aquí y allá" tan bien como lo hacen las máquinas.Las subclases establecen separaciones más claras.

Así que mis reglas personales para el parcheo de monos son:

• Si puedes hacerlo sin el parche de mono y funcionará bien, no uses el parche de mono.
• Puede agregar nuevos métodos a las clases, pero no puede modificar los existentes.
• Hágalo de una manera muy visible y obvia, es decir.un archivo llamado string_extensions.rb en su /lib, no en un /myvendor/submodule/se.rb oculto.
• Debería ser local;las clases que no utilizan una biblioteca no deberían verse afectadas.

Ahora, a tu ejemplo:Clip de papel.

• Que yo sepa, agrega métodos a sus clases ActiveRecord, pero no modifica las existentes.
• Tienes que agregar un has_attachment directiva para las clases que usan clip, de lo contrario no se ven afectadas.

Entonces los cambios son localizados y obvios (de hecho, creo que logran mejorar depuración:es más fácil de leer para nosotros los humanos has_attachment en lugar de class MyModel < Paperclip::ActiveRecordWithAttachment).

La creación de subclases también es una mala idea en este caso porque no podría usar un clip además de otro complemento que usara subclases: Rails se hereda de forma única.

Y en el caso de Paperclip, es claramente un has_a relación con su apego, no una is_a uno.Se podría argumentar que no sería un uso adecuado de la subclasificación.

Finalmente, me gustaría señalar que Paperclip requiere subclases en algunas ocasiones (debes usar subclases para crear un procesador de clips).