El patrón Estrategia de diseño de software

El patrón Estrategia
Fecha de la última revisión: 21.05.2014
Revisión 3.0 (21.05.2014)
Miguel Ángel Abián
1. Introducción
En este artículo se expone el patrón Estrategia desde dos puntos de vista: el teórico y el práctico. Por un lado, se explican los argumentos
teóricos para usar este patrón; por otro, se dan algunos consejos para saber cuándo conviene usarlo y se exponen tres ejemplos completos
de su uso en Java. Para seguir el artículo, no se necesita ningún conocimiento previo que no sea comprender, aun someramente, el
lenguaje Java.
Según la última versión del diccionario de la Real Academia Española, un patrón es "el modelo que sirve de muestra para sacar otra cosa
igual". Aunque la definición no usa ningún término informático, se adecua bastante bien al sentido con que se emplea patrón en la
ingeniería del software. En esta disciplina, los patrones no son muestras físicas o ejemplares a partir de los cuales se puedan construir cosas
iguales; sino representaciones abstractas que sirven para especificar y documentar soluciones recurrentes a ciertos problemas habituales.
Pese a lo mucho que se usan los patrones de software, no abundan las definiciones del término "patrón de software". Más aún: incluso el
creador del término patrón en el sentido de buena práctica (aplicado a la arquitectura, no a la construcción de software) parecía sentirse
más cómodo escribiendo un libro voluminoso, abstracto y, a ratos, confuso que definiendo de forma clara y precisa el concepto de patrón.
Una definición que no hará mal a nadie es la que aparece en [1]:
[Un patrón] es una descripción en un formato fijo de cómo resolver un cierto tipo de problemas.
Según Brad Appleton (la definición la leí hace cuatro o cinco años en http://www.enteract.com/~bradapp/docs/pattern-intro.html; la
dirección ya no funciona), un patrón es
[...] una unidad de información instructiva con nombre, la cual captura la estructura esencial y la compresión de una familia de soluciones
exitosas probadas para un problema recurrente que ocurre dentro de un cierto contexto y de un sistema de fuerzas.
La definición más completa que conozco para el término aparece en [2] y es obra de James Coplien:
Un patrón es una regla constituida por tres partes; la cual expresa una relación entre un cierto contexto, un cierto sistema de fuerzas que
ocurren repetidamente en ese contexto y una cierta configuración de software que permite a estas fuerzas resolverse a sí mismas.
Según esta definición, tres son las partes fundamentales de un patrón: un sistema de fuerzas, un contexto y una configuración de
software.
Sistema de fuerzas es el término que usa Coplien como generalización del tipo de criterios que usan los ingenieros de software y los
programadores para argumentar sus diseños e implementaciones. Cada vez que se diseña o implementa un componente de software, las
fuerzas son los objetivos y restricciones que deben considerar ingenieros y programadores para el componente. Hallar una solución de
software para un problema es solucionar el sistema de fuerzas asociado al problema. Una fuerza puede ser la velocidad de ejecución, el
consumo de memoria RAM, la interoperabilidad con otros programas, la existencia de errores, etc.
La expresión configuración de software es usada por Coplien para denotar cualquier conjunto de reglas de diseño susceptible de ser utilizado
para solucionar un sistema de fuerzas. Solucionar un sistema de fuerzas es encontrar un equilibrio óptimo entre las fuerzas que afectan al
sistema. Dependiendo de la naturaleza de las fuerzas, puede ser imposible demostrar formalmente que una solución equilibra de forma
óptima (esto es, resuelve) un sistema de fuerzas. Por ejemplo, si una fuerza es el impacto social o político, no puede probarse
analíticamente que una solución es óptima (al menos, no con las técnicas matemáticas actuales).
Por último, contexto es el entorno en que se enmarca un sistema de fuerzas. Un contexto dado puede hacer inservibles ciertas
configuraciones de software o hacer que unas sean preferible a otras.
En definitiva, la definición de Coplien plantea que un patrón es una descripción genérica de una solución recurrente para un problema
recurrente condicionado por la consecución de ciertos objetivos sujetos a ciertas restricciones.
El concepto de patrón en el sentido que usamos aquí procede del campo de la arquitectura: fue el arquitecto Christopher Alexander quien
primero manejó el término, basándose en los temas recurrentes en el diseño de edificios y calles; más tarde, la idea fue transplantada al
dominio del diseño de software. Cuando analizó la historia de la Arquitectura, Alexander encontró diseños y construcciones que se repetían
en zonas geográficas muy alejadas y de culturas muy distintas. Por ejemplo, los tejados de las casas de los pueblos pequeños eran y son
muy similares (están hechos de tejas, tienen una gran pendiente), aunque las necesidades de los habitantes han debido ser muy distintas
(éstas dependen de factores geográficos, climáticos y personales). La persistencia de estos tejados es un indicio de que existe una solución
óptima (un patrón) para la construcción de tejados que se ha venido copiando, con pequeñas variaciones y quizás de forma inconsciente, en
muchos pueblos del mundo. Según Alexander,
Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente y después describe la parte más importante de la
solución a ese problema de tal manera que se pueda utilizar esta solución un millón de veces, sin hacerlo dos veces de la misma manera.
En uno de sus libros [3], aparece como ejemplo de patrón de diseño arquitectónico el de las "Ventanas de la Calle", que reproduzco aquí.
Copyright (c) 2004-2014, Miguel Ángel Abián. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de
Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en http://www.javahispano.org/licencias/).
Page 1 of 24El patrón Estrategia
21/05/2014file://F:ArticuloEclipseVersiónDefinitivaCopia de patronE...

Los patrones de software se pueden dividir en distintas categorías. En el libro [4], los patrones se clasifican en:
Patrones de diseño. Ofrecen esquemas para refinar subsistemas y componentes de un sistema de software, o las relaciones entre
ellos. Por lo general, describen una estructura de comunicación recurrente entre componentes, que sirve para resolver un problema
general de diseño en un contexto determinado.
Patrones arquitectónicos. Expresan una organización estructural básica para un sistema de software, organización referida a un
conjunto de subsistemas predefinidos. Asimismo, especifican las responsabilidades de estos subsistemas y proporcionan directrices y
reglas para organizar las relaciones entre ellos.
Patrones de implementación (idioms). Estos patrones son de bajo nivel de abstracción, pues están asociados a lenguajes de
programación concretos; describen cómo implementar ciertas características de los componentes de software o de sus relaciones
haciendo uso de las estructuras y propiedades de un lenguaje de programación. Por ejemplo, en C++, el código while (*destino++ =
*src++); es un patrón de implementación para copiar cadenas de caracteres.
Según la bibliografía técnica, los patrones de diseño ofrecen las siguientes ventajas:
Facilitan la reutilización del diseño. Usando patrones de diseño, se pueden reusar diseños de software en tantas aplicaciones como se
quiera, aun cuando éstas se escriban en distintos lenguajes de programación.
Simplifican el proceso de diseño. Si en la fase de análisis uno encuentra un problema para el cual existe un patrón de diseño, ya tiene
hecha más de la mitad del trabajo: no necesita comenzar el diseño desde cero.
Facilitan la transmisión de los conocimientos adquiridos por otros programadores. Usando patrones de diseño, los programadores
neófitos pueden aprender rápidamente cómo piensan los diseñadores expertos.
Proporcionan un vocabulario común y consistente para el diseño de software. Esta característica facilita la comunicación entre
diseñadores. Hablar de patrones es más abstracto que hablar de clases o interfaces.
Acercan el desarrollo de software a lo que se espera de una ingeniería. El desarrollo de un vocabulario común y de una lista de
buenas prácticas es común a cualquier ingeniería.
Muestran buenos principios de diseño. Principios como el encapsulado, la abstracción y la cohesión entran desde el principio en los
patrones de diseño.
Ayudan a comprender las bibliotecas de clases que los usan. Java, por ejemplo, tiene muchos paquetes que se han construido
basándose en patrones de diseño.
El libro más influyente en cuanto a patrones de diseño en software es [5], que define patrón de diseño como "una descripción de clases y
objetos que se comunican entre sí, adaptada para resolver un problema de diseño general en un contexto particular". Es un libro nuevo,
pero no original: clasifica y organiza unas ideas que ya llevaban cierto tiempo en el aire. Debido a su popularidad y predicamento, este libro
es de lectura obligada para quien quiera asomarse al mundo de los patrones. En él se distinguen tres tipos de patrones de diseño para
software: patrones de creación, de comportamiento y estructurales:
Patrones de creación. Son patrones que abstraen el proceso de creación de los objetos. Se dividen en patrones de creación de
clases (el patrón Método de fábricas -Factory Method-, por ejemplo) y de creación de objetos (el patrón Constructor -Builder-, p. ej.).
Patrones de comportamiento. Estos patrones asignan responsabilidades y algoritmos a los objetos. Se dividen en patrones de
comportamiento de objetos (el patrón Observador -Observer-, por ejemplo) y de comportamiento de clases (el patrón Método de
plantillas -Template Method-, p. ej.).
Figura 1. Un patrón de diseño arquitectónico: las ventanas de la calle. Una casa sin ventanas es fría y poco acogedora.
Asimismo, es desagradable estar en un casa que dé a una calle sin ninguna ventana

Patrones estructurales. Son patrones que definen cómo deben combinarse las clases y los objetos para solucionar eficazmente
ciertos problemas. Se dividen en patrones estructurales de objetos (el patrón Adaptador -Adapter-, por ejemplo) y en patrones
estructurales de clases (el patrón en patrones estructurales de clases (el patrón Compuesto o Entidad compuesta -Composite-, p.
ej.).
En javaHispano existe una serie de artículos sobre patrones [6], obra de Alberto Molpeceres; así como un tutorial muy completo[7], obra de
Martín Pérez. Si el lector desea conocer más patrones, le recomiendo leer estos trabajos. El presente artículo es una acotación marginal a
ellos.
2. El patrón Estrategia
Según [5], el patrón Estrategia "define una familia de algoritmos, encapsula cada uno y los hace intercambiables. La Estrategia deja que el
algoritmo varíe independientemente de los clientes que lo usen" (página 315).
Me he decidido a escribir sobre este patrón por varios motivos:
Es un patrón muy útil para seguir el Principio Abierto/Cerrado ("Una entidad de software -clase, módulo, etcétera- debe estar abierta
para su extensión, pero cerrada para su modificación").
Muestra el poder del polimorfismo en los lenguajes orientados a objetos.
Al basarse en el encapsulado y en la programación de interfaces, constituye un buen ejemplo de la aplicación de los principios del
diseño orientado a objetos.
En el principio Abierto/Cerrado, "debe estar abierta para su extensión" significa que no se ha de cambiar una clase existente cuando se
extiendan sus funciones; "cerrada para su modificación" significa que deben existir subclases o clases abstractas o interfaces en las que
delegar las nuevas funciones que se desee añadir. Para que el principio Abierto/Cerrado no quede en mera palabrería o en una montaña de
buenas intenciones, se necesitan varios ingredientes: abstracción, encapsulado, polimorfismo, herencia e interfaces. No por casualidad,
estas herramientas son el núcleo de la verdadera programación orientada a objetos. Sin ellas, un programa escrito en Java, Smalltalk o
C++ sería tan orientado a objetos como melódico es el chirriar de una bisagra oxidada.
Para entender las implicaciones del principio Abierto/Cerrado, se puede considerar el siguiente código, correspondiente a un método que
calcula el importe total de la compra en un supermercado:
public double calcularImporteVenta(Producto productos[]) {
double importeTotal = 0.00;
for (i=0; i < productos.length; i++) {
importeTotal += producto[i] * getPrecio();
}
return importeTotal;
}
Tal y como está escrito el método CalcularImporteVenta(), cumple perfectamente el principio Abierto/Cerrado. Consideremos ahora que la
inflación se está disparando en el país donde se encuentra el supermercado y que sus dueños, comprometidos con el bienestar del país y
con los estrictos criterios macroeconómicos del Fondo Monetario Internacional, deciden rebajar el precio de los alimentos que más influyen
sobre la inflación: el pan y la carne de pollo. Sí, algo de ironía hay en el ejemplo; pero ¿no es irónico que una institución de países
industrializados proponga políticas y prácticas antiproteccionistas que ningún país industrializado ha seguido nunca? En fin, el código del
método anterior quedaría así:
public double calcularImporteVenta(Producto productos[]) {
double importeTotal = 0.00;
for (i=0; i < productos.length; i++) {
if (productos[i] instanceof BarraPan)
importeTotal += producto[i] * 0.85 * getPrecio();
else if (productos[i] instanceof Pollo)
importeTotal += producto[i] * 0.90 * getPrecio();
else
importeTotal += producto[i] * getPrecio();
}
return importeTotal;
}
Este código ya no cumple el principio Abierto/Cerrado. Si la lista de productos alimentarios que influyen en la inflación cambiara, habría que
añadir nuevos productos y eliminar otros. Se incumpliría, pues, la condición de cerrado para modificaciones. Tal como se verá en la sección
4, el patrón Estrategia permite cumplir el principio.
La representación UML del patrón Estrategia se muestra en la figura 2.

Las clases que aparecen en la figura se explican aquí:
Contexto. Un objeto Contexto es un cliente que usa una operación de la interfaz ofrecida por EstrategiaAbstracta. Por tanto,
mantiene una referencia a un objeto que es instancia de alguna clase de las derivadas por herencia de la clase EstrategiaAbstracta.
Contexto desconoce qué clases implementarán la operación o cómo lo harán.
EstrategiaAbstracta. Esta clase define el comportamiento fundamental de las clases Estrategia. Al ser una clase abstracta o una
interfaz (en Java o C#), no pueden crearse instancias de ella. Para realizar operaciones, los clientes deben usar instancias de sus
subclases concretas.
EstrategiaConcreta1, EstragegiaConcreta2, etc. Las instancias de estas clases especializan el comportamiento básico
especificado por EstrategiaAbstracta. La especialización se consigue mediante la implementación de las operaciones de
EstrategiaAbstracta o la definición de otras nuevas. Los objetos cliente tienen referencias a instancias de estas clases.
En Java, las subclases de EstrategiaAbstracta se derivan de ésta mediante extends (si ésta es una clase abstracta) o implements (si es una
interfaz). Existen situaciones sencillas en las que la clase EstrategiaAbstracta puede ser sustituida por una clase que implementa los
comportamientos deseados; en este caso, no se necesitan las clases EstrategiaConcreta1, EstragegiaConcreta2, etc. Al final de la siguiente
sección se pondrá un ejemplo de esta situación, la cual correspondería a lo que puede denominarse "patrón Estrategia degenerado".
Cuando se aplica a un problema, el patrón Estrategia rompe el diseño en dos partes claramente diferenciadas: la del Contexto y la de la
Estrategia. La primera parte es la parte invariante del diseño, pues su comportamiento no cambia de vez en vez. La segunda (formada por
la clase EstrategiaAbstracta y sus subclases) aprehende la naturaleza cambiante y modificable del diseño: cada subclase de
EstrategiaConcreta define un comportamiento específico que puede necesitarse cuando el programa esté en ejecución. En cierto modo, el
patrón Estrategia aprovecha el mecanismo de la herencia para sacar factor común de los distintos algoritmos.
Existen varios modos de colaboración entre la Estrategia y el Contexto que permiten elegir el comportamiento deseado en cada ocasión. Los
dos más habituales se detallan aquí:
Un objeto Contexto puede pasar a un objeto Estrategia, cuando sea necesario, todos los datos necesarios para el método que
implementa el comportamiento deseado. La gran ventaja de trabajar así radica en que se consigue desacoplar el Contexto de la
Estrategia.
Un Contexto puede pasar una referencia a sí mismo como argumento de los métodos que implementan las operaciones de la interfaz
de Estrategia. De este modo, la Estrategia puede llamar al Contexto cada vez que lo necesite. La desventaja de obrar así es que se
aumenta el acoplamiento entre Contexto y Estrategia.
Normalmente, los clientes que necesitan las operaciones de la Estrategia no acceden directamente a los métodos que las implementan, sino
que interaccionan solamente con el Contexto (que, a su vez, es un cliente de la Estrategia). Los clientes crean y pasan objetos del tipo
EstrategiaConcreta a objetos Contexto, que se encargan de pasar las peticiones a la Estrategia.
3. Usos del patrón Estrategia
De modo general, resulta conveniente emplear el patrón Estrategia cuando los clientes implementan algoritmos genéricos que son difíciles
de reusar, de intercambiar y cuya elección puede variar en tiempo de ejecución. Un buen indicio de lo anterior lo da la proliferación
Figura 2. Estructura del patrón Estrategia

cancerosa de expresiones condicionales en el código (if, switch/case).
Por ejemplo, consideremos que se quiere escribir una aplicación encargada de cifrar texto mediante claves. Dada una clave y un texto, la
aplicación debe generar un texto indescifrable para cualquiera que no tenga la clave con la que se codificó el texto. Consideremos también
que existen varias implementaciones para el algoritmo de cifrado. Los motivos para esta multiplicidad no son teóricos: dependiendo de la
longitud del texto, puede haber implementaciones más eficaces que otras, pueden existir implementaciones más rápidas pero que
consuman más recursos (memoria, espacio en el disco duro, etc.)...
Una solución a nuestro problema sería colocar toda la lógica del negocio en la clase cliente (la que usa los algoritmos). Mediante sentencias
condicionales, el código del cliente elegiría el algoritmo de cifrado que necesitara. Esta solución dista de ser idónea: según se fueran
incorporando nuevas implementaciones del algoritmo, aumentaría el número de sentencias condicionales y se necesitaría modificar el código
del cliente, así como recompilarlo. Aparte, sería imposible cifrar dinámicamente un texto mediante diferentes algoritmos.
Otra solución consistiría en escribir una clase general cuyas subclases encapsularan cada una de las implementaciones del algoritmo de
cifrado. Los problemas de esta otra solución no serían despreciables: seguiría siendo necesario mantener las sentencias condicionales, se
dispararía el número de subclases y el comportamiento seguiría fijado en tiempo de compilación. Un objeto, pongamos por caso,
Implementacion1 no podría comportarse como un objeto Implementacion2 durante la ejecución del programa: una vez creado, su
comportamiento sería inmodificable.
Para este problema, el patrón Estrategia proporciona una excelente solución. Basta seguir estos pasos:
Identifíquese el comportamiento deseado (cifrado del texto mediante una clave).
Especifíquese la interfaz del comportamiento en una clase abstracta o en una interfaz (EstrategiaAbstracta).
Desplácese todo el código basado en sentencias condicionales a cada una de las subclases concretas de EstrategiaAbstracta.
Cada vez que se necesite una implementación concreta del algoritmo de cifrado, deléguese la petición a un objeto (Contexto) que
contenga referencias a objetos del tipo EstrategiaAbstracta.
Con el patrón Estrategia, cada vez que se necesita añadir nuevas implementaciones del algoritmo de cifrado, no se precisará modificar el
cliente ni el Contexto: sólo habrá que añadir una nueva clase EstrategiaConcreta. Como los clientes usan la interfaz de métodos definida por
EstrategiaAbstracta (es decir, su tipo, no la clase), un mismo objeto Texto podrá ser cifrado con todas las implementaciones.
¿Cuándo conviene usar el patrón Estrategia?
Cuando hay muchas clases interrelacionadas que difieren solamente en comportamiento. Este patrón proporciona un modo de
configurar el comportamiento deseado sin modificar el tipo de cada objeto.
Cuando se necesitan distintas variantes de un mismo algoritmo.
Cuando un algoritmo usa datos que no queremos que sean visibles para los clientes. El patrón Estrategia permite evitar que los
clientes conozcan las estructuras de datos que se usen internamente.
He aquí algunas situaciones en las que se cumple una o varias de las condiciones expuestas arriba:
Representación gráfica de unos mismos datos en distintas formas (gráfico de barras, de porciones, etc.).
Compresión de ficheros en distintos formatos (Zip, GZip, Rar, etc.).
Grabación de ficheros en distintos formatos (HTML, PDF, Word, etc.).
Utilización de distintas políticas de seguridad en el acceso a los recursos de una red.
Encaminamiento de paquetes IP mediante diversos algoritmos (la elección dependerá del estado de las redes, del tráficos de datos,
de la distancia entre redes, etc.).
Ordenación o búsqueda de elementos en una colección por medio de distintos algoritmos (método de la burbuja, búsqueda
secuencial, etc.)
4. Algunos ejemplos del patrón Estrategia
No necesitamos recurrir al software para ver ejemplos del patrón Estrategia. La propia realidad nos ofrece unos cuantos. Consideremos, por
ejemplo, una agencia de viajes; en la figura 3 se muestra su representación UML.

Como es bien sabido, una agencia de viajes ofrece el servicio de proporcionar viajes a sus clientes. Mediante ella, una persona puede
seleccionar el viaje deseado (medio de transporte, precio, destino) entre los que la agencia pone a disposición de los clientes. Según el
patrón Estrategia, el cliente interacciona con la agencia de viajes para seleccionar el comportamiento deseado para su viaje.
El patrón Estrategia también puede usarse para plantear asuntos más existenciales. Vivimos en una época en que la adolescencia se
prolonga hasta los treinta, en que la juventud es el valor supremo y en que algunas empresas se jactan de que la media de edad de sus
plantillas no supera los treinta y cinco años (empresas, por cierto, que omiten dar la edad media de sus directivos: si tanto importa la
juventud del personal, ¿por qué no tienen directores y presidentes con menos de cincuenta años?). El patrón Estrategia también sirve para
recordarnos el orden natural de las cosas:
Figura 3. Una agencia de viajes

Dependiendo de la edad de una persona, la Vida elige una especialización de Persona (Niño, Adulto o Anciano). El patrón Estrategia permite
que estas especializaciones añadan sus propios comportamientos especializados al comportamiento base definido en Persona: trabajar(),
balbucear(), cobrarPension().
Si nos restringimos a la aplicación del patrón Estrategia al software, podemos considerar el ejemplo que aparece en [5] (página 315),
consistente en un programa para dividir un texto en líneas (por ejemplo, con espaciado sencillo o doble). Gamma et al. razonan que resulta
desaconsejable escribir el código de los algoritmos de inserción de saltos de línea dentro de las clases que necesiten dichos algoritmos. Tres
son los motivos aducidos:
Los clientes se volverían más complejos si incluyeran el código de todos los algoritmos para colocar los saltos de línea.
Sería difícil modificar los algoritmos existentes y añadir nuevos.
Algunos clientes tendrían algoritmos para la inserción de saltos de línea que raras veces, o nunca, usarían.
La solución que proponen Gamma et al. consiste en aplicar el patrón Estrategia del modo representado en la figura 5.
En este ejemplo, la clase Composition mantiene una colección de instancias Component, que representan texto y elementos gráficos en un
documento. Un objeto Composition organiza los objetos componentes dependiendo de la manera de insertar saltos de línea que se adopte.
La clase Composition se encarga de mantener y actualizar los saltos de línea del texto que se muestra en un visor de texto. Cada estrategia
para aplicar los saltos de línea se implementa en subclases de la clase abstracta Compositor:
La clase SimpleCompositor implementa una estrategia simple que determina los saltos de línea de uno en uno.
La clase TeXCompositor implementa el algoritmo TeX para encontrar saltos de línea (se buscan y actualizan saltos de línea párrafo a
párrafo).
Figura 4. La vida segun el patrón Estrategia
Figura 5. Ejemplo extraído del libro Design Patterns: Elements of Reusable Object-Oriented Software

La clase ArrayCompositor implementa una estrategia que selecciona los saltos de línea de modo que cada columna tenga un número
fijo de elementos.
Un objeto Composition (que representa un bloque de texto) mantiene una referencia a un objeto Compositor. Cuando un objeto
Composition vuelve a componer su texto, delega esta responsabilidad en el objeto Compositor asociado. Los clientes de Composition (un
procesador de textos, por ejemplo), especifican qué Compositor se usará eligiendo el objeto Compositor al cual se hará referencia dentro del
Composition.
Otro ejemplo de uso del patrón Estrategia nos lo proporciona el paquete java.awt. Las instancias de la clase Component del AWT declaran
las instancias de la clase Contexto que permiten seleccionar y establecer distintos algoritmos de distribución de los componentes gráficos
mediante el método SetLayout() de la interfaz LayoutManager (la clase EstrategiaAbstracta para este ejemplo), encargada de distribuir los
componentes gráficos en el componente AWT. Las subclases de LayoutManager (BorderLayout, BoxLayout, FlowLayout, ScrollPaneLayout,
etc.) encapsulan su propia implementación de setLayout().
Si consideramos la aplicación de la sección anterior que se encargaba de cifrar texto mediante claves, el patrón Estrategia nos daría una
solución como la que se representa en la figura:
Figura 6. El patrón Estrategia en el AWT

Sin el patrón Estrategia, la implementación del programa de codificación de textos tendría un método similar a éste:
public void cifrar(String clave, String bloqueTexto, int algoritmo) {
// Método de la clase Texto, que representa textos que van a codificarse.
if (algoritmo == ALGORITMO_X)
CifrarConAlgoritmoX(clave, bloqueTexto);
if (algoritmo == ALGORITMO_y)
CifrarConAlgoritmoY(clave, bloqueTexto);
...
}
Con el patrón Estrategia, el método quedaría así:
public setAlgoritmoCifrado(Cifrado cifrado) {
// Método de la clase Texto, que representa textos que van a cifrarse.
// Se escoge el algoritmo de cifrado en tiempo de ejecución.
this.cifrado = cifrado;
}
public void cifrar(String clave, String bloqueTexto) {
// Método de la clase Texto, que representa textos que van a cifrarse.
cifrado.codificar(clave, bloqueTexto);
}
Cualquier videojuego donde se pueda seleccionar un personaje según la etapa del juego, el entorno, las características de los enemigos,
etc., es un buen ejemplo del patrón Estrategia. El cliente que elige, dependiendo de las condiciones, un personaje dado está eligiendo una
estrategia concreta, que hereda de una estrategia abstracta, con métodos básicos y comunes para todas sus subclases. Los programadores
de un videojuego no programan diferentes algoritmos de localización de los objetos y de representación gráfica de los mismos. Dicho de
otro modo: la manera de dibujar los píxeles de un ogro o de una encantadora dama no varía, ni tampoco varían los algoritmos generales
como los de detección de colisiones, etc. Todos los personajes tienen los mismos. Ahora bien, dependiendo del personaje, cambian los
píxeles que lo representan, así como el comportamiento frente a los ataques del enemigo, la resistencia, la habilidad con ciertas armas, etc.
Esos comportamientos específicos se definen en las estrategias concretas, mientras que en la estrategia abstracta se definen los
comportamientos generales.
En la figura 8 se muestra el patrón Estrategia para un videojuego donde el jugador puede elegir un personaje humano, leonino o batracio.
Cada Estrategia concreta (Humano, Leon, Batracio) tendrá su propia implementación de los métodos luchar(arma, energia, duracionAtaque)
y huir (velocidadHuida), pues es de suponer que una rana no huirá con la misma gracia y velocidad que un león; pero las tres subclases
recurriran a los métodos de la superclase Personaje para métodos como dibujarPixel(x, y), borrarPixel(x, y), MoverPixel(x_inic, y_inic,
x_dest, y_dest), etc.
Figura 7. El patrón Estrategia en el ejemplo de cifrado

Por último, otro ejemplo de la aplicación del patrón Estrategia lo proporciona el ejemplo de los productos de un supermercado que se vio en
la sección 2. En lugar del código que no cumple el principio Abierto/Cerrado, el patrón permite escribir este código:
public class Producto {
private String nombre;
private double precio;
private Descuento descuento;
public Producto(String nombre) {
this.nombre = nombre;
}
public void setDescuento(Descuento descuento) {
this.descuento = descuento;
}
public void setPrecio(double precio) {
this.precio = precio;
}
public double getPrecio() {
return descuento.getPrecio(precio);
}
}
public class Descuento {
private double factor; //factor de descuento
public Descuento(double factor) {
this.factor = factor;
}
public double getPrecio(double precio) {
return precio * factor;
}
}
En este ejemplo, la clase EstrategiaAbstracta es una clase que implementa directamente sus métodos (es decir, no es abstracta ni una
interfaz); en consecuencia, son innecesarias sus subclases. Con esta solución se puede cambiar dinámicamente los descuentos de cualquier
producto del supermercado, sin modificar el código ya escrito. Por ejemplo, si se quiere fijar el descuento del pollo en un 10%, bastará
escribir:
Producto pollo = new Producto("pollo");
pollo.setPrecio(30.05);
Figura 8. El patrón Estrategia en un videojuego

pollo.setDescuento(new Descuento(0.90));
A la vista del código de las dos últimas clases, se puede formular lo que se conoce como un corolario del principio Abierto/Cerrado: "Si un
sistema de software debe permitir un conjunto de alternativas, lo ideal es que una sola clase en el sistema conozca el conjunto completo de
alternativas".
5. Tres ejemplos de implementación en Java del patrón Estrategia
En esta sección se exponen de forma completa tres ejemplos de uso del patrón Estrategia con Java. Los dos primeros son versiones
simplificadas de situaciones ante las que me he encontrado en mi actividad profesional. Son, pues, aplicaciones completamente prácticas del
patrón. Innegable es que usar este patrón exige un poco de reflexión y planificación previas; pero creo que merece la pena: uno ahorra
mucho tiempo cuando tiene que introducir cambios o mejoras. Y no hay que engañarse: los clientes siempre piden mejoras, modificaciones o
refinamientos para sus aplicaciones (está en su naturaleza). Anticiparse a esos cambios de manera que se modifique lo menos posible el
código o los módulos ya escritos suele ser una buena práctica (al menos, si uno no cobra por horas de trabajo).
El tercer ejemplo se aleja mucho del mundo empresarial: consiste en usar el patrón Estrategia para modelar osciladores amortiguados
clásicos (no cuánticos). Aparte de para estudiar muelles y resortes, los osciladores amortiguados son muy útiles para analizar estructuras
periódicas de átomos o moléculas. De hecho, el ejemplo se me ocurrió cuando analizaba los modos de vibración de una red de difracción
tridimensional.
5.1. Un programa de cálculo de precios con descuentos
Consideremos que se nos encarga una aplicación de contabilidad para una tienda de muebles que clasifica sus productos en tres tipos:
mueble clásico, mueble kit y mueble de diseño. Dependiendo del tipo de mueble, la tienda hace un descuento por cada venta: mueble clásico,
un 5%; mueble kit, un 10%; y mueble moderno, un 15%.
Supongamos también que desconocemos el patrón Estrategia y que somos novatos en la programación orientada a objetos. Entonces,
nuestro primer intento sería algo como (omito los métodos get y set que no voy a usar y casi todos los comentarios):
package mobiliario;
/**
* Intento sin el patrón Estrategia: clase Mueble.
* Representa un mueble del catálogo de la tienda.
*
*/
public class Mueble {
private double precio; // Precio del catálogo.
private String codigo; // Código en el catálogo.
private int tipo; // Tipo de mueble: clásico, kit o moderno.
public static final int CLASICO = 0;
public static final int KIT = 1;
public static final int MODERNO = 2;
return precio;
}
public String getCodigo() {
return codigo;
}
public int getTipo() {
return tipo;
}
public Mueble(String codigo, double precio, int tipo) throws ExcepcionTipoMueble {
if ( (tipo > Mueble.MODERNO) || (Mueble.CLASICO > tipo) )
throw new ExcepcionTipoMueble();
else {
this.codigo = codigo;
this.tipo = tipo;
}
}
}
package mobiliario;
/**
* Intento sin el patrón Estrategia: clase VentaMueble.
* Esta clase representa la venta de un mueble del catálogo de la tienda
*/
import java.util.*;
public class VentaMueble {
private Date fecha; // Fecha de la venta.
private Mueble mueble; // Mueble que se vende.

public Date getFecha() {
return fecha;
}
public VentaMueble(Mueble mueble){
fecha = new Date();
this.mueble = mueble;
}
public double calcularPrecioVenta() throws ExcepcionTipoMueble {
// El precio de venta tiene un descuento con respecto al del catálago.
if (mueble.getTipo()==Mueble.CLASICO){
return (mueble.getPrecio())*0.95;
}
else if (mueble.getTipo()==Mueble.KIT){
}
else if (mueble.getTipo()==Mueble.MODERNO){
}
else
throw new ExcepcionTipoMueble();
}
// Ejemplo de funcionamiento del programa.
public static void main(String args[]) throws ExcepcionTipoMueble {
VentaMueble vm = new VentaMueble (new Mueble("Sofá Dalí", 1800.65, Mueble.MODERNO));
System.out.println("Precio de venta: " + vm.calcularPrecioVenta());
}
}
package mobiliario;
/**
* Intento sin el patrón Estrategia: clase ExceptionTipoMueble.
* Esta excepción se lanza cuando se introduce un tipo de mueble inválido.
*
*/
public class ExcepcionTipoMueble extends Exception {
public ExcepcionTipoMueble() {
super("Compruebe el tipo de mueble introducido.");
}
}
Los problemas de introducir toda la lógica del negocio en el código del cliente ya se vieron, de modo general, en la sección 3. En este
ejemplo, los problemas concretos son dos:
Si se introdujera un nuevo tipo de mueble en el catálogo de la tienda, habría que modificar el código del cliente.
Si se cambiaran los descuentos (por ejemplo, en época de rebajas), habría que modificar el código del cliente. El cliente está
fuertemente acoplado con la política de descuentos.
Nuestra primera solución es muy inestable: mínimos cambios llevan a reprogramar el cliente y a recompilarlo. Si utilizamos el patrón
Estrategia, obtendríamos una solución similar a ésta (vuelvo a omitir los métodos get y set que no voy a usar y casi todos los comentarios):
package mobiliario;
/**
* Interfaz Descuento (Solución con el patrón Estrategia).
* Esta interfaz es la estrategia abstracta.
*/
public interface Descuento {
public double calcularPrecioVenta(double precio);
}
package mobiliario;
/**
* Interfaz DescuentoMuebleClasico (Solución con el patrón Estrategia).
* Esta clase es una de las estrategias concretas.
*/
public class DescuentoMuebleClasico implements Descuento {
// Constructor
public DescuentoMuebleClasico() {
}
// Devuelve el precio con el descuento.
public double calcularPrecioVenta(double precio) {
return (precio * 0.95);
}

}
package mobiliario;
/**
* Interfaz DescuentoMuebleKit (Solución con el patrón Estrategia).
*/
public class DescuentoMuebleKit implements Descuento {
// Constructor
public DescuentoMuebleKit() {
}
}
}
package mobiliario;
/**
* La interfaz DescuentoMuebleModerno (Solución con el patrón Estrategia).
*/
public class DescuentoMuebleModerno implements Descuento {
// Constructor
public DescuentoMuebleModerno() {
}
}
}
package mobiliario;
/**
* Clase Mueble (solución con el patrón Estrategia).
* Representa un mueble del catálogo de la tienda.
* Esta clase es el contexto.
*/
private Descuento desc; // Tipo de descuento.
return precio;
}
return codigo;
}
public Descuento getDescuento() {
return desc;
}
public Mueble(String codigo, double precio, Descuento desc) throws Exception {
if ( (desc == null) ) {
// Cuando se crea un objeto Mueble, es obligatorio introducir su descuento.
throw new Exception("Debe introducir un tipo de descuento");
}
else {
this.desc = desc;
}
}
}
package mobiliario;
/**
* Clase VentaMueble (solución con el patrón Estrategia).
* Esta clase representa la venta de un mueble del catálogo de la tienda.
* Es cliente de la clase Mueble (el contexto para este caso).
*/
import java.util.*;

private Mueble mueble; // Mueble vendido.
return fecha;
}
this.fecha = new Date();
}
public double calcularPrecioVenta() throws Excepcion {
return (mueble.getDescuento().calcularPrecioVenta(mueble.getPrecio()));
}
public static void main(String[] args) throws Exception {
Mueble m = new Mueble ("Silla Luis XVI", 1300.67, new DescuentoMuebleClasico());
VentaMueble vm = new VentaMueble (m);
System.out.println ("Código: " + m.getCodigo());
System.out.println("Precio de catálogo: " + m.getPrecio());
}
}
La segunda solución presenta ventajas significativas con respecto a la primera: ahora podemos añadir nuevos tipos de descuento sin
modificar la clase Mueble ni la clase VentaMueble. Si se quiere incluir un nuevo descuento, basta añadir una nueva clase que implemente la
interfaz Descuento.
En el caso de que se desee optar por una política de descuentos personalizada para cada mueble, el patrón Estrategia permite escribir una
solución como ésta:
package mobiliario;
/**
* Clase Descuento (Solución con el patrón Estrategia para el caso de políticas personalizadas
* de descuentos).
*/
public class Descuento {
private double factorDescuento; // Factor de descuento.
public Descuento (double factorDescuento) {
this.factorDescuento = factorDescuento;
}
return (factorDescuento * precio);
}
}
package mobiliario;
/**
* Clase Mueble (solución con el patrón Estrategia para el caso de políticas personalizadas
* de descuentos).
*/
private Descuento desc; // Tipo de descuento.
return precio;
}
return codigo;
}
public Descuento getDescuento() {
return desc;
}
public Mueble(String codigo, double precio, Descuento desc) throws Exception {
if ( (desc == null) ) {
// Cuando se crea un objeto Mueble, es obligatorio introducir su descuento.
throw new Exception("Debe introducir un tipo de descuento");
}
else {

this.desc = desc;
}
}
}
package mobiliario;
/**
* Clase VentaMueble (solución con el patrón Estrategia para el caso de políticas personalizadas
* de descuentos).
*/
import java.util.*;
private Mueble mueble; // Mueble vendido.
return fecha;
}
this.fecha = new Date();
}
public double calcularPrecioVenta() throws Exception {
return (mueble.getDescuento().calcularPrecioVenta(mueble.getPrecio()));
}
public static void main(String[] args) throws Exception {
Mueble m = new Mueble ("Silla Barcelona", 4560.18, new Descuento(0.90));
VentaMueble vm = new VentaMueble (m);
System.out.println ("Código: " + m.getCodigo());
System.out.println("Precio de catálogo: " + m.getPrecio());
}
}
5.2. Un programa de cálculo de amortizaciones
Consideremos ahora que estamos trabajando en un módulo de software para llevar la contabilidad de una empresa y que hemos llegado a la
parte del cálculo de amortizaciones de los bienes de la empresa (máquinas, ordenadores, mobiliario, mercancías, etc.). Según el Plan General
Contable, la amortización es "la expresión de la depreciación sistemática, anual y efectiva sufrida por el inmovilizado inmaterial y material por
su incorporación al sistema productivo".
En principio, la Hacienda española admite varias maneras de calcular la amortización: la amortización mediante tablas, la amortización lineal,
la amortización degresiva por suma de dígitos y la amortización degresiva en progresión decreciente. Consideremos también que la empresa
para la cual trabajamos sólo emplea los tres últimos tipos de cálculo. Lógicamente, los contables de la empresa desearán poder elegir el
cálculo de amortización que haga máxima, para cada bien, la amortización; así podrán pagar menos a la Hacienda pública.
El patrón Estrategia parece un buen candidato para echarnos una mano en el diseño de la parte de las amortizaciones: contamos con un
comportamiento abstracto (algo así como Amortizacion) que se particulariza en comportamientos concretos (AmortizacionDegresivaDigitos,
AmortizacionLineal, AmortizacionProgresionDecreciente).
Veamos una posible forma de implementar el cálculo de amortizaciones con el patrón Estrategia (incorporo documentación javadoc al
código):
package amortizacion;
/**
* Esta interfaz es la estrategia abstracta del patron Estrategia.
*
*/
public interface Amortizacion {
/**
*
* @param precio Precio del bien.
* @param valorResidual Valor del bien al final de su vida útil.
* @param vida Años de vida útil del bien.
* @param anyo Anualidad para la cual se quiere calcular la amortización del bien.
* @return Amortización correspondiente al año anyo.
* @throws Excepcion
*/
public double calcularAmortizacion (double precio, double valorResidual, int vida, int anyo) throws Excepcion;
}

/**
* AmortizacionLineal es una estrategia concreta del patrón Estrategia.
* Implementa el cálculo de la amortización lineal (cuotas fijas).
*/
public class AmortizacionLineal implements Amortizacion {
/**
*
* @throws Excepcion
*/
public double calcularAmortizacion (double precio, double valorResidual, int vida, int anyo) throws Excepcion {
// Comprobación de los argumentos
if ( (precio > 0) && (anyo > 0) && (vida > 0) && (vida >= anyo) && (valorResidual < precio) ) {
return ( (precio - valorResidual) / vida );
} else
throw new Excepcion();
}
/**
* Constructor sin argumentos.
*/
public AmortizacionLineal() {
}
}
/**
* AmortizacionDegresivaDigitos es una estrategia concreta del patrón Estrategia.
* Implementa el cálculo de la amortización degresiva por suma de dígitos.
*/
public class AmortizacionDegresivaDigitos implements Amortizacion {
/**
*
* @throws Excepcion
*/
return ( (precio - valorResidual) * ( (vida - anyo + 1.0) / ( (vida * (vida + 1)) / 2.0) ) );
} else
}
/**
*/
public AmortizacionDegresivaDigitos() {
}
}
/**
* AmortizacionProgresionDecreciente es una estrategia concreta del patrón Estrategia.
* Implementa el cálculo de la amortización degresiva en progresión decreciente.
*/
class AmortizacionProgresionDecreciente implements Amortizacion {
/**
*
* @throws Excepcion
*/
double a = valorResidual / precio;
double b = (1./vida);
double t = (1. - Math.pow(a, b));
return ( precio * t * Math.pow((1 - t), anyo - 1) );
} else

}
/**
*/
public AmortizacionProgresionDecreciente() {
}
}
public class Excepcion extends Exception {
public Excepcion() {
super("Compruebe los valores introducidos en los parametros.");
}
}
/**
* Esta clase es el contexto del patrón Estrategia.
*/
public class Bien {
/**
* Precio del bien.
*/
private double precio;
/**
* Valor del bien al final de su vida útil.
*/
private double valorResidual;
/**
* Años de vida útil del bien.
*/
private int vida;
/**
* Estrategia de amortización.
*/
private Amortizacion amortizacion;
/**
* Método set para precio.
*/
public void setPrecio(double precio) {
}
/**
* Método get para valorResidual.
* @return Valor residual del bien.
*/
public double getValorResidual() {
return valorResidual;
}
/**
* Método set para valorResidual.
*
* @param valorResidual double
*/
public void setValorResidual(double valorResidual) {
this.valorResidual = valorResidual;
}
/**
* Método get para precio
* @return Precio del bien
*/
return precio;
}
/**
* Método set para vida.
*
*/
public void setVida(int vida) {
this.vida = vida;
}
/**
* Método get para vida.
* @return Años de vida útil del bien.

*/
public int getVida() {
return vida;
}
/**
* Método set para Amortizacion.
*
* @param amort Estrategia de amortizacion
*/
public void setAmortizacion(Amortizacion amort) {
this.amortizacion = amort;
}
/**
* Constructor
*
* @param valorResidual Valor residual del bien.
* @param vida Vida útil del bien.
* @param amort Estrategia de amortización.
*/
public Bien(double precio, double valorResidual, int vida, Amortizacion amort) {
this.valorResidual = valorResidual;
this.vida = vida;
if (amort == null) {
this.amortizacion = new AmortizacionLineal();
} else
this.amortizacion = amort;
}
public void CambiarTipoAmortizacion (Amortizacion amort) {
if (amort != null)
setAmortizacion(amort);
}
public void calcularAmortizacion(int anyo) throws Excepcion {
System.out.println(amortizacion.calcularAmortizacion(precio, valorResidual, vida, anyo));
}
}
/**
* Esta clase es cliente de la clase Bien.
*
*/
public class Cliente {
// Ejemplo de uso del programa. Se calculan la amortizaciones al segundo año.
public static void main(String args[]) {
try {
Bien bien = new Bien(60000., 5000., 10, null);
bien.calcularAmortizacion(2);
bien.CambiarTipoAmortizacion(new AmortizacionProgresionDecreciente());
bien.CambiarTipoAmortizacion(new AmortizacionDegresivaDigitos());
}
catch (Exception e) {
e.printStackTrace();
}
}
}
5.3. Un programa de cálculo de posiciones para osciladores amortiguados.
En el mundo físico hay muchos movimientos que son oscilatorios. El movimiento oscilatorio más sencillo es el denominado movimiento
armónico simple. Cualquier sistema que experimente una fuerza restauradora lineal es candidato a ser considerado un oscilador armónico
simple. La ecuación de movimiento para un oscilador armónico simple que oscila en una sola dirección es (k es la constante elástica del
oscilador)
O dicho de otra manera:
La solución a la ecuación diferencial de segundo grado es la siguiente:

Donde A y el ángulo phi son constantes que se determinan al especificar unas condiciones iniciales (en Matemáticas se suelen llamar
condiciones de contorno).
En cualquier sistema oscilatorio real existen fuerzas de fricción que tienden a provocar que el movimiento se detenga al cabo de un tiempo
(este tipo de movimiento se conoce como movimiento armónico amortiguado). La ecuación general para un oscilador armónico amortiguado
es (lambda es la constante de amortiguación del oscilador)
O lo que es lo mismo:
Esta ecuación diferencial admite tres clases de soluciones:
1) Solución amortiguada (cuando gamma es menor que omega0)
La solución general es:
Si se imponen estas condiciones iniciales: t=0, x=0, v=v0, la solución queda así:
2) Solución crítica (cuando gamma es igual a omega0)
3) Solución sobreamortiguada (cuando gamma es mayor que omega0)
En este ejemplo, se van a implementar los distintos casos de un oscilador armónico amortiguado usando el patrón Estrategia (en la figura
se muestra la aplicación del patrón para este ejemplo).

package oscilador;
/**
* Esta interfaz es la estrategia abstracta del patrón Estrategia.
*
*/
public interface Fuerza {
public double calcularPosicionX(double t);
}
package oscilador;
/**
* FuerzaAmortiguadora es una estrategia concreta del patrón Estrategia.
*/
public class FuerzaAmortiguadora implements Fuerza{
/**
* Frecuencia del movimiento. (w^2 = w0^2 - gamma^2)
*/
private double omega;
/**
* Coeficiente de amortiguación del movimiento. ( gamma = lambda/(2m) )
*/
private double gamma;
/**
* Método para calcular la posición del oscilador en el instante t.
*
* @param t double
*/
public double calcularPosicionX(double t) {
return ( (1./omega) * Math.exp(-gamma * t) * Math.sin(omega * t) );
}
/**
* Constructor.
*
* @param omega0 double
Figura 9. Aplicación del patrón Estrategia al análisis de los osciladores amortiguados

* @param gamma double
*/
public FuerzaAmortiguadora(double omega0, double gamma) throws Exception {
if ( (omega0 > 0) && (gamma > 0) ) {
this.omega = Math.sqrt( (omega0 * omega0) - (gamma * gamma));
this.gamma = gamma;
}
else
throw new Exception("Revise las constantes del movimiento");
}
}
package oscilador;
/**
* FuerzaCritica es una estrategia concreta del patrón Estrategia.
*/
public class FuerzaCritica implements Fuerza{
/**
* Frecuencia del movimiento. (w^2 = w0^2 - gamma^2)
*/
private double omega;
/**
*
* @param t double
*/
return ( t * Math.exp(-omega * t) );
}
/**
* Constructor.
*
*/
public FuerzaCritica(double omega0) throws Exception {
if ( (omega0 > 0) )
this.omega = omega0;
else
}
}
package oscilador;
/**
* FuerzaSobreAmortiguadora es una estrategia concreta del patrón Estrategia.
*/
public class FuerzaSobreAmortiguadora implements Fuerza{
/**
* Coeficiente beta del movimiento (beta^2 = gamma^2 - w0^2)
*/
private double beta;
/**
* Coeficiente de amortiguación del movimiento. ( gamma = lambda/(2m) )
*/
/**
*
* @param t double
*/
return ( (1./beta) * Math.exp(-gamma * t) * ( (Math.exp(beta * t) - (Math.exp(-beta * t)) )/2. ) );
}
/**
* Constructor.
*
*/
public FuerzaSobreAmortiguadora(double omega0, double gamma) throws Exception {
if ( (omega0 > 0) && (gamma > 0) ) {
this.beta = Math.sqrt( (gamma * gamma) - (omega0 * omega0) );
this.gamma = gamma;
}
else

}
}
package oscilador;
/**
* OsciladorAmortiguado es el contexto del patrón Estrategia.
*/
public class OsciladorAmortiguado {
/**
* Frecuencia natural del oscilador.(omega0^2) = k/m
*/
private double omega0;
/**
* Coeficiente de amortiguamiento del movimiento. gamma = lambda/(2m)
*/
/**
* Velocidad inicial en el tiempo t=0.
*/
private double v0;
/**
* Tipo de fuerza.
*/
private Fuerza fuerza;
/**
* Método set para fuerza.
*
* @param fuerza Fuerza
*/
public void setFuerza(Fuerza fuerza) {
this.fuerza = fuerza;
}
/**
*
* @param t double
*/
return(v0 * fuerza.calcularPosicionX(t));
}
/**
* Constructor
*
* @param fuerza Fuerza
*/
public OsciladorAmortiguado(double omega0, double gamma, double v0) throws Exception {
this.omega0 = omega0;
this.gamma = gamma;
this.v0 = v0;
if (gamma < omega0)
setFuerza(new FuerzaAmortiguadora(omega0, gamma));
else if (gamma == omega0)
setFuerza (new FuerzaCritica(omega0));
else if (gamma > omega0)
setFuerza (new FuerzaSobreAmortiguadora(omega0, gamma));
else
throw new Exception("Debe elegir obligatoriamente un tipo de oscilador amortiguado");
}
// Ejemplo del funcionamiento del programa
public static void main (String args[]) throws Exception {
// Oscilador sobreamortiguado
OsciladorAmortiguado oa1 = new OsciladorAmortiguado(0.1, 0.2, 1.1);
System.out.println(oa1.calcularPosicionX(5.)); // Posición a los cinco segundos
// Oscilador amortiguado
System.out.println(oa2.calcularPosicionX(2.)); // Posición a los dos segundos
// Oscilador crítico
System.out.println(oa3.calcularPosicionX(3.)); // Posición a los tres segundos
}
}
6. Ventajas y desventajas del patrón Estrategia.

El patrón Estrategia proporciona cuatro grandes ventajas:
Permite definir familias de algoritmos relacionados, lo que posibilita agrupar funciones comunes y facilitar la reutilización del código.
Es una cómoda alternativa a la subclasificación. Para compartir comportamientos suelen generarse subclases y redefinir los métodos
comunes. Este patrón permite que el comportamiento cambie dinámicamente, en tiempo de ejecución.
Elimina el uso de sentencias condicionales (if, switch/case), cuyo abuso hace difícil de leer el código. En lugar de comprobar
dinámicamente que comportamiento hay que elegir, la elección se hace cuando se crea un objeto Estrategia.
Permite al cliente elegir entre diversas implementaciones de una misma operación.
Pese a que [5] señala explícitamente como ventaja del patrón Estrategia la eliminación de sentencias condicionales, creo que esa ventaja se
debe al polimorfismo, no al patrón Estrategia.
Como no podía ser de otra manera, el patrón Estrategia presenta inconvenientes. Los dos más importantes son éstos:
Incrementa el número de objetos que pueden ejecutarse en una aplicación.
Puede sobrecargar innecesariamente la aplicación si algunas implementaciones de los algoritmos no necesitan todos los argumentos
necesitados por una EstrategiaAbstracta. Un método de la estrategia abstracta puede declarar muchos argumentos innecesarios para
casi todas las estrategias concretas, que habrá que pasar cada vez que se escoja una estrategia concreta, sean usados o no por ella.
Por ejemplo, considérese un método hacerAlgo(ArrayList al, HashMap hm, HashSet hs) de una estrategia abstracta. Por estar
declarado en la estrategia abstracta, todas las estrategias concretas deberán implementarlo y deberán recibir los argumentos al, hm
y hs, aun cuando sólo usen uno de ellos. Como dentro de una colección puede haber cientos o miles de objetos, puede generarse un
tráfico de datos innecesario. Una manera de paliar el paso de información innecesaria es aumentar el acoplamiento entre las
estrategias y el contexto, de manera que el segundo delegue en las primeras.
Los clientes deben conocer la existencia de las distintas estrategias. Si los clientes ignoran las estrategias o les resultan indiferentes,
el uso del patrón resulta inapropiado.
Recursos
[1] Working with Objects. The OORam Software Engineering Method, Trygve Reenskaug , Prentice Hall , ISBN 0134529308
[2] A Pattern Definition - Software Patterns, http://hillside.net/patterns/definition.html
[3] A Pattern Language : Towns, Buildings, Construction, Christopher Alexander, Sara Ishikawa y Murray Silverstein , Oxford
University Press , ISBN 0195019199
[4] Pattern-Oriented Software Architecture, Volume 1: A System of Patterns, Frank Buschmann, Regine Meunier, Hans
Rohnert, Peter Sommerlad, Michael Stal, Peter Sommerlad y Michael Stal , John Wiley & Sons , ISBN 0471958697
[5] Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson y John
Vlissides , Addison-Wesley Pub Co , ISBN 0201633612
[6] Artículos sobre ingeniería del software en javaHispano, http://www.javahispano.org/articles.list.action?section=5
[7] Tutoriales sobre ingeniería del software en javaHispano, http://www.javahispano.org/tutorials.type.action?type=is
Acerca del autor
Miguel Ángel Abián
Miguel Ángel Abián nació en Soria. Obtuvo la suficiencia investigadora en el Dpto. de Física Aplicada de la Universidad de Valencia con una
tesina sobre electromagnetismo. Realizó varios cursos de doctorado relacionados con electromagnetismo, electrónica, semiconductores y
cristales fotónicos. Ha recibido becas del IMPIVA (Instituto de la Mediana y Pequeña Industria Valenciana) y de la Universidad Politécnica de
Valencia. Cursó un Máster estadounidense en UML y Java y otro sobre tecnologías de Internet/Intranet.
Se incorporó en 1998 a AIDIMA, donde ha participado como investigador en 24 proyectos de investigación nacionales e internacionales
relacionados con la Web semántica, tecnologías de la información, madera en construcción, biosensórica, bioelectrónica,
telecomunicaciones, visión artificial; así como en la Red de Excelencia de la Comisión Europea INTEROP 2003-2007. Algunos de los
proyectos europeos relacionados con las tecnologías semánticas en los que ha participado son ATHENA y STASIS (http://www.stasis-
project.net/).
El año 2006 estuvo cuatro meses como investigador invitado en el departamento Lehrstuhl für Messsystem und Sensortechnik de la
Universidad Politécnica de Munich (TUM), donde colaboró en el desarrollo de nuevos métodos para la detección de defectos en superficies
acabadas y en el diseño e implementación de sistemas distribuidos de sensores para el sector del automóvil y de energías renovables. En
2007 recibió un premio BANCAJA-UPV por un proyecto relacionado con la calidad interna de la madera. En 2009 recibió el premio
internacional Schweighofer Innovation Prize -el premio más prestigioso en el sector forestal y de la madera- por su aportación al desarrollo
de nuevas tecnologías de evaluación no destructiva de la madera en construcción.
Actualmente es Responsable del Departamento de Tecnología y Biotecnología de la Madera y del Área de Construcción de Madera.
Es coautor de 7 libros y guías técnicas relacionadas con el uso de la madera en la construcción y la visión artificial. También ha publicado
varios artículos científicos en revistas como IEEE Transactions on Microwave Theory and Techniques y Wood Science and Technology. Ha
participado como ponente en congresos y conferencias como European Congress on Computational Methods in Applied Sciences and
Engineering, IEEE International Conference on Multisensor Fusion and Integration for Intelligent Systems, International Conference on
Space Structures (IABSE-IASS) y en reuniones COST (European Cooperation in Science and Technology). Ha publicado más de 22 artículos
técnicos en revistas sectoriales y técnicas.
Es autor o coautor de 8 patentes, algunas de ellas en trámite. Tres de ellas corresponden a dispositivos y métodos para detectar la
biodegradación de la madera en construcción.
Actualmente, entre otros proyectos como SHBUILDINGS, WOODTECH, WOODRUB y CELLUWOOD, ha trabajado en SEMCONCEPT, un
proyecto de I+D+i para aplicar tecnologías semánticas (ontologías, buscadores semánticos) en el diseño conceptual de productos
industriales. Sus intereses actuales son la evolución de la programación orientada a objetos, Java, la Web semántica y sus tecnologías, la
arquitectura orgánica, el surrealismo y París, siempre París.

of 24El patrón Estrategia

El patrón Estrategia de diseño de software

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie El patrón Estrategia de diseño de software

Ähnlich wie El patrón Estrategia de diseño de software (20)

Mehr von torrubia

Mehr von torrubia (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

El patrón Estrategia de diseño de software