design-patterns - pattern - patrones de diseño

¿Utiliza el patrón de método de plantilla en los lenguajes de programación con cierres/delegados/indicadores de función?

Question

He estado yendo y viniendo entre C # y Java durante los últimos 8 años.

Una cosa que me llama la atención es que he dejado de usar por completo el patrón de diseño "Método de plantilla" en C #. De hecho, en C # I he llegado a pensar en este patrón como un antipatrón.

http://en.wikipedia.org/wiki/Template_method_pattern

Volviendo a Java, encuentro que el patrón está vivo y coleando. Sigo pensando que parece antiguo, pero me doy cuenta de que no hay otra forma de hacerlo en Java. Java también se ve antiguo;)

Dado que esto va a surgir de todos modos, ¿por qué es un antipatrón?

• Muchas veces utiliza su jerarquía de herencia por "las razones incorrectas".
• Las clases base tienen una tendencia a estar plagadas de todo tipo de código no relacionado.
• Te obliga a bloquear el diseño, a menudo bastante temprano en el proceso de desarrollo. (Bloqueo prematuro en muchos casos)
• Cambiar esto en una etapa posterior se vuelve cada vez más difícil.

Por lo tanto, con los cierres / delegados / indicadores de funciones, normalmente se pasa alguna función en lugar de subclasificar.

Volviendo a la pregunta:

Si su idioma tiene cierres / delegados / función, ¿usa el Método de plantilla y cuándo?

Answer 1

Cuando utilicé Java, sí. Pero para los idiomas con "cierres / delegados / función", Lua en mi caso, no, ya no, en cambio me he inclinado más y más hacia el patrón de decoración para la mayoría de mis necesidades.

Answer 2

Sí, utilizo el método de la plantilla todo el tiempo, en el lenguaje de programación D. Los cierres, los delegados y los indicadores de función son, por su naturaleza, muy poco compactos con la clase base. Esto es bueno cuando quieres este acoplamiento flexible. Por otro lado, a veces los comportamientos que está personalizando son, por su naturaleza, muy vinculados a la clase base. Tales comportamientos serían inútiles en casi cualquier otro contexto. En los casos donde este acoplamiento es necesario, el patrón del método de la plantilla es la forma más limpia y simple de expresarlo.

Una prueba simple es que siempre se debe usar estrategia / cierres / delegados / indicadores de función si la comunicación entre la clase base y el comportamiento personalizable es unidireccional, es decir, la clase base llama al comportamiento personalizable y eso es todo. Si el comportamiento personalizable necesita una referencia a la clase base para que pueda invocar métodos, etc., el patrón de método de la plantilla suele ser la forma más sencilla de proceder.

Answer 3

Agregaré una respuesta más mientras repaso este hilo:

El patrón de método de plantilla es mejor que el patrón de estrategia cuando las políticas con las que está personalizando su objeto base necesitan conocerse entre sí y solo pueden tener sentido en un subconjunto muy limitado de todas las combinaciones posibles. Por ejemplo, supongamos que su clase base tiene una función concreta doIt() y enlaza beforeDoIt() , diseñada para permitir que las políticas se inicialicen a sí mismas y afterDoIt() , diseñadas para permitir que las políticas se afterDoIt() por sí mismas. No querrá establecer estos comportamientos de forma independiente porque solo tienen sentido cuando se emparejan.