Diferencia entre revisiones de «Strategy»

Línea 1: Línea 1:
{{Normalizar|motivo=Mejorar vínculos internos...}}
 
 
{{Definición
 
{{Definición
 
|nombre= [[Estrategia]] / [[Strategy]]
 
|nombre= [[Estrategia]] / [[Strategy]]
Línea 8: Línea 7:
 
<div align="justify">
 
<div align="justify">
 
   
 
   
'''Strategy.''' El patrón Estrategia ([[Strategy]]) es un patrón de diseño para el desarrollo de [[software]]. Se clasifica como patrón de comportamiento porque determina como se debe realizar el intercambio de mensajes entre diferentes objetos para resolver una tarea.
+
'''Strategy.''' El patrón Estrategia / [[Strategy]] es un patrón de diseño para el desarrollo de [[software]]. Se clasifica como patrón de comportamiento porque determina como se debe realizar el intercambio de mensajes entre diferentes objetos para resolver una tarea. Los patrones de diseño se han convertido en una técnica importante para el reuso de conocimiento de software. Cada patrón provee información sobre su diseño, describiendo las clases, métodos y relaciones que resuelven un problema de diseño en particular.
 
   
 
   
 
==Tipo==
 
==Tipo==
Línea 16: Línea 15:
 
==Propósito==
 
==Propósito==
 
   
 
   
Permite a los algoritmos variar con independencia de los clientes que los usan.
+
Permite a los algoritmos variar con independencia de los clientes que los usan. El propósito de un patrón de diseño es capturar el conocimiento de un diseño de software y hacerlo reusable.
 
   
 
   
==Cuando usarlo==
+
==¿Cuándo usarlo?==
 
   
 
   
 
*Cuando muchas clases relacionadas sólo se diferencian en su comportamiento.
 
*Cuando muchas clases relacionadas sólo se diferencian en su comportamiento.
Línea 32: Línea 31:
 
   
 
   
 
*Las familias jerárquicas de estrategias definen algoritmos y comportamientos que enfatizan la reutilización.  La herencia puede ayudar a sacar factor común a la funcionalidad de los algoritmos.
 
*Las familias jerárquicas de estrategias definen algoritmos y comportamientos que enfatizan la reutilización.  La herencia puede ayudar a sacar factor común a la funcionalidad de los algoritmos.
*El encapsulamiento de algoritmos en clases separadas ofrece una ventajosa alternativa a la especialización por herencia del contexto para obtener un comportamiento diferente, que promueve la independencia, la facilidad de entender el diseño y la posibilidad de futuras extensiones.
+
*El encapsulamiento de [[algoritmos]] en clases separadas ofrece una ventajosa alternativa a la especialización por herencia del contexto para obtener un comportamiento diferente, que promueve la independencia, la facilidad de entender el diseño y la posibilidad de futuras extensiones.
 
*Se eliminan las costosas definiciones de comportamiento multicondicionales.
 
*Se eliminan las costosas definiciones de comportamiento multicondicionales.
 
*Se posibilita ofrecer diferentes implementaciones del mismo comportamiento, en función de restricciones como el espacio en memoria o el tiempo de respuesta.
 
*Se posibilita ofrecer diferentes implementaciones del mismo comportamiento, en función de restricciones como el espacio en memoria o el tiempo de respuesta.
Línea 59: Línea 58:
 
*[http://tratandodeentenderlo.blogspot.com/2010/11/patrones-de-diseno-strategy.html blogspot.com]
 
*[http://tratandodeentenderlo.blogspot.com/2010/11/patrones-de-diseno-strategy.html blogspot.com]
 
*[http://desasoftware.blogspot.com/2011/01/strategy-patron-de-diseno.html desasoftware.com]
 
*[http://desasoftware.blogspot.com/2011/01/strategy-patron-de-diseno.html desasoftware.com]
+
*[http://www.dcc.uchile.cl/~mmarin/revista-sccc/sccc-web/Vol5/wis3.pdf uchile.cl]
 +
 
 
[[Category: Informática]][[Category:Programación]]
 
[[Category: Informática]][[Category:Programación]]

Revisión del 08:40 22 feb 2012

Información sobre la plantilla
Strategy5.png
Concepto:Define una familia de algoritmos encapsulando por separado cada uno de ellos y haciéndolos, por tanto, intercambiables.

Strategy. El patrón Estrategia / Strategy es un patrón de diseño para el desarrollo de software. Se clasifica como patrón de comportamiento porque determina como se debe realizar el intercambio de mensajes entre diferentes objetos para resolver una tarea. Los patrones de diseño se han convertido en una técnica importante para el reuso de conocimiento de software. Cada patrón provee información sobre su diseño, describiendo las clases, métodos y relaciones que resuelven un problema de diseño en particular.

Tipo

Comportamiento, a nivel de objetos.

Propósito

Permite a los algoritmos variar con independencia de los clientes que los usan. El propósito de un patrón de diseño es capturar el conocimiento de un diseño de software y hacerlo reusable.

¿Cuándo usarlo?

  • Cuando muchas clases relacionadas sólo se diferencian en su comportamiento.
  • Cuando se necesitan diferentes variantes de un algoritmo.
  • Cuando un algoritmo usa datos que los clientes no tienen porque conocer.
  • Cuando una clase define muchos comportamientos, los cuales se manifiestan como definiciones condicionales múltiples de sus operaciones.

Implementación

Las posibles estrategias se ejecutan dentro de un objeto de contexto que se encarga de recuperar la estrategia apropiada para el cliente. Cada una de las estrategias implementa una interfaz que define la firma del método de la estrategia.

Ventajas

  • Las familias jerárquicas de estrategias definen algoritmos y comportamientos que enfatizan la reutilización. La herencia puede ayudar a sacar factor común a la funcionalidad de los algoritmos.
  • El encapsulamiento de algoritmos en clases separadas ofrece una ventajosa alternativa a la especialización por herencia del contexto para obtener un comportamiento diferente, que promueve la independencia, la facilidad de entender el diseño y la posibilidad de futuras extensiones.
  • Se eliminan las costosas definiciones de comportamiento multicondicionales.
  • Se posibilita ofrecer diferentes implementaciones del mismo comportamiento, en función de restricciones como el espacio en memoria o el tiempo de respuesta.

Inconvenientes

  • Los clientes deben tener un cierto conocimiento de cada estrategia, para así poder elegir en cada situación cual es la más apropiada.
  • Dado que todas las estrategias comportan una interfaz común, si las diferencias entre ellas es grande, es probable que mucha de la información que se les pasa no sea de utilidad más que a las más complejas.
  • Puede producirse una gran explosión en el número de objetos del sistema.

Esto se puede aliviar si las estrategias se implementan como objetos sin estado que los contextos pueden compartir.

Otros aspectos de interés

  • Si el “Contexto” pasa a la “Estrategia” los datos como parámetros de las operaciones de esta última se mantiene un acoplamiento débil, pero la eficiencia se puede resentir (puede que haya “Estrategias” que reciban datos que no necesitan). Si el “Contexto” se pasa a sí mismo como parámetro o la “Estrategia” mantiene una referencia al “Contexto” se resuelve este último problema a cambio de un mayor acoplamiento.
  • Los clientes configuran al “Contexto” con una “Estrategia” determinada, con la cual el “Contexto” interactúa para producir un comportamiento determinado. Para tal fin, el “Contexto” puede definir una interfaz que permita a la “Estrategia” acceder a sus datos internos.
  • Existe la posibilidad de que el “Contexto” defina un comportamiento por defecto y sólo en el caso de que los clientes deseen otra cosa se le configure con la “Estrategia” correspondiente.
  • En C++, en el caso de que la “Estrategia” se fije en tiempo de compilación y se vaya a cambiar en ejecución se pueden usar plantillas (templates) para configurar un “Contexto” con una “Estrategia”.

Ejemplo de aplicación

En un editor de texto pueden existir múltiples algoritmos para dividir un documento en líneas (algoritmo simple, algoritmo TEX, algoritmo matricial, etc....), siendo deseable que la complejidad de los mismos quede oculta al cliente y que sea fácil y cómodo el cambio sobre la marcha de uno por otro o la adición de nuevos algoritmos al sistema.

Fuente